Hi, everyone!
I've been trying to connect to a WPA3 (personal, not enterprise)
network but, as expected, the connection always fails with hardware
encryption (most likely due to mandatory MFP, which the hardware won't
do). What I didn't expect was to have the exact same problem when
using software crypto. I've tried with other devices, and they work
fine. One thing I noticed is this: for example, a Ralink RT2790
device, on another machine, shows the following supported cyphers with
hardware crypto…
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
… and with software crypto…
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
* CMAC (00-0f-ac:6)
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
… while b43 shows exactly the same in both modes…
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
This is a BCM4318 device (PCI ID 14e4:4318), but I don't know if
that's relevant.
Is this behaviour expected?
Thanks in advance,
Rui
On 5/19/20 9:18 AM, Rui Salvaterra wrote:
> Hi, everyone!
>
> I've been trying to connect to a WPA3 (personal, not enterprise)
> network but, as expected, the connection always fails with hardware
> encryption (most likely due to mandatory MFP, which the hardware won't
> do). What I didn't expect was to have the exact same problem when
> using software crypto. I've tried with other devices, and they work
> fine. One thing I noticed is this: for example, a Ralink RT2790
> device, on another machine, shows the following supported cyphers with
> hardware crypto…
>
> * WEP40 (00-0f-ac:1)
> * WEP104 (00-0f-ac:5)
> * TKIP (00-0f-ac:2)
> * CCMP-128 (00-0f-ac:4)
> * CCMP-256 (00-0f-ac:10)
> * GCMP-128 (00-0f-ac:8)
> * GCMP-256 (00-0f-ac:9)
>
> … and with software crypto…
>
> * WEP40 (00-0f-ac:1)
> * WEP104 (00-0f-ac:5)
> * TKIP (00-0f-ac:2)
> * CCMP-128 (00-0f-ac:4)
> * CCMP-256 (00-0f-ac:10)
> * GCMP-128 (00-0f-ac:8)
> * GCMP-256 (00-0f-ac:9)
> * CMAC (00-0f-ac:6)
> * CMAC-256 (00-0f-ac:13)
> * GMAC-128 (00-0f-ac:11)
> * GMAC-256 (00-0f-ac:12)
>
> … while b43 shows exactly the same in both modes…
>
> * WEP40 (00-0f-ac:1)
> * WEP104 (00-0f-ac:5)
> * TKIP (00-0f-ac:2)
> * CCMP-128 (00-0f-ac:4)
> * CCMP-256 (00-0f-ac:10)
> * GCMP-128 (00-0f-ac:8)
> * GCMP-256 (00-0f-ac:9)
>
> This is a BCM4318 device (PCI ID 14e4:4318), but I don't know if
> that's relevant.
> Is this behaviour expected?
>
> Thanks in advance,
> Rui
>
Rui,
From other drivers, it appears that handling WPA3 might be as simple as setting
MFP_CAPABLE in the hardware capabilities. Please try this patch:
diff --git a/drivers/net/wireless/broadcom/b43/main.c
b/drivers/net/wireless/broadcom/b43/main.c
index 39da1a4c30ac..e944fe2e9ac7 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -4162,8 +4162,11 @@ static int b43_op_set_key(struct ieee80211_hw *hw, enum
set_key_cmd cmd,
int err;
static const u8 bcast_addr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff,
0xff };
- if (modparam_nohwcrypt)
+ if (modparam_nohwcrypt) {
+ /* User disabled HW-crypto - enable MFP (WPA3) */
+ ieee80211_hw_set(hw, MFP_CAPABLE);
return -ENOSPC; /* User disabled HW-crypto */
+ }
if ((vif->type == NL80211_IFTYPE_ADHOC ||
vif->type == NL80211_IFTYPE_MESH_POINT) &&
I have no way of testing other than to compile.
Larry
Hi, Larry,
On Tue, 19 May 2020 at 21:30, Larry Finger <[email protected]> wrote:
>
> From other drivers, it appears that handling WPA3 might be as simple as setting
> MFP_CAPABLE in the hardware capabilities. Please try this patch:
Fantastic, thanks for the quick reply! I will do it ASAP and get back to you.
> I have no way of testing other than to compile.
No problem, I have two different revisions of b43 cards to test (on
x86 and ppc32 machines). :)
Thanks a lot,
Rui
On Tue, 19 May 2020 at 21:36, Rui Salvaterra <[email protected]> wrote:
>
> Hi, Larry,
>
> On Tue, 19 May 2020 at 21:30, Larry Finger <[email protected]> wrote:
> >
> > From other drivers, it appears that handling WPA3 might be as simple as setting
> > MFP_CAPABLE in the hardware capabilities. Please try this patch:
>
> Fantastic, thanks for the quick reply! I will do it ASAP and get back to you.
Unfortunately, looks like in this driver it's not so simple, the
association is still rejected. I looked at the other drivers too and,
sure enough, they just set the MFP_CAPABLE flag unconditionally with
software crypto (I would expect mac80211 to magically handle it, but
with b43 it doesn't seem to be the case).
On 5/19/20 6:13 PM, Rui Salvaterra wrote:
> On Tue, 19 May 2020 at 21:36, Rui Salvaterra <[email protected]> wrote:
>>
>> Hi, Larry,
>>
>> On Tue, 19 May 2020 at 21:30, Larry Finger <[email protected]> wrote:
>>>
>>> From other drivers, it appears that handling WPA3 might be as simple as setting
>>> MFP_CAPABLE in the hardware capabilities. Please try this patch:
>>
>> Fantastic, thanks for the quick reply! I will do it ASAP and get back to you.
>
> Unfortunately, looks like in this driver it's not so simple, the
> association is still rejected. I looked at the other drivers too and,
> sure enough, they just set the MFP_CAPABLE flag unconditionally with
> software crypto (I would expect mac80211 to magically handle it, but
> with b43 it doesn't seem to be the case).
It is necessary to load the driver with option nohwcrypt set to 1. I expect that
you probably did that, but I forgot to mention it.
It would likely help if you can get verbose logs from wpa_supplicant.
Larry
Hi, Larry,
On Wed, 20 May 2020 at 01:16, Larry Finger <[email protected]> wrote:
>
> It is necessary to load the driver with option nohwcrypt set to 1. I expect that
> you probably did that, but I forgot to mention it.
Yes, of course. I don't use modules, so I pass b43.nohwcrypt=1 in the
kernel command line. I confirmed in sysfs the nohwcrypt parameter is
correctly set to 1.
> It would likely help if you can get verbose logs from wpa_supplicant.
No problem! Attached is a wpa_supplicant -d log. Let me know if you
need extra verbosity.
Thanks,
Rui
On Wed, 20 May 2020 at 09:24, Rui Salvaterra <[email protected]> wrote:
>
> Hi, Larry,
>
> On Wed, 20 May 2020 at 01:16, Larry Finger <[email protected]> wrote:
> >
> > It is necessary to load the driver with option nohwcrypt set to 1. I expect that
> > you probably did that, but I forgot to mention it.
>
> Yes, of course. I don't use modules, so I pass b43.nohwcrypt=1 in the
> kernel command line. I confirmed in sysfs the nohwcrypt parameter is
> correctly set to 1.
>
> > It would likely help if you can get verbose logs from wpa_supplicant.
>
> No problem! Attached is a wpa_supplicant -d log. Let me know if you
> need extra verbosity.
>
> Thanks,
> Rui
By the way, I just tested with WPA2 forcing MFP (pmf=3 in the Network
Manager connection) and it also doesn't connect.
On 5/20/20 5:55 AM, Rui Salvaterra wrote:
> On Wed, 20 May 2020 at 09:24, Rui Salvaterra <[email protected]> wrote:
>>
>> Hi, Larry,
>>
>> On Wed, 20 May 2020 at 01:16, Larry Finger <[email protected]> wrote:
>>>
>>> It is necessary to load the driver with option nohwcrypt set to 1. I expect that
>>> you probably did that, but I forgot to mention it.
>>
>> Yes, of course. I don't use modules, so I pass b43.nohwcrypt=1 in the
>> kernel command line. I confirmed in sysfs the nohwcrypt parameter is
>> correctly set to 1.
>>
>>> It would likely help if you can get verbose logs from wpa_supplicant.
>>
>> No problem! Attached is a wpa_supplicant -d log. Let me know if you
>> need extra verbosity.
>>
>> Thanks,
>> Rui
>
> By the way, I just tested with WPA2 forcing MFP (pmf=3 in the Network
> Manager connection) and it also doesn't connect.
I found this line in the b43 logs:
nl80211: NL80211_CMD_SET_PMKSA failed: -95 (Operation not supported)
Could we also see the supplicant log for the RaLink driver that works?
Larry
On Wed, 20 May 2020 at 21:08, Larry Finger <[email protected]> wrote:
>
> I found this line in the b43 logs:
> nl80211: NL80211_CMD_SET_PMKSA failed: -95 (Operation not supported)
>
> Could we also see the supplicant log for the RaLink driver that works?
Sure thing, here you go! This one's much shorter, since the connection
was successful.
On 5/20/20 3:28 PM, Rui Salvaterra wrote:
> On Wed, 20 May 2020 at 21:08, Larry Finger <[email protected]> wrote:
>>
>> I found this line in the b43 logs:
>> nl80211: NL80211_CMD_SET_PMKSA failed: -95 (Operation not supported)
>>
>> Could we also see the supplicant log for the RaLink driver that works?
>
> Sure thing, here you go! This one's much shorter, since the connection
> was successful.
A quick difference - this one supports 3 additional ciphers:
vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:13
vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:11
vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:12
The one with :13 is for BIP-CMAC-256, :11 is BIP-GMAC-128, and :12 is
BIP-GMAC-256. I did not find a reference that says that these are needed for
WPA3, but I am suspicious.
Thus far, I have not found where the driver tells nl80211 what should be supported.
Perhaps, we were calling ieee80211_hw_set() in the wrong place. Try
diff --git a/drivers/net/wireless/broadcom/b43/main.c
b/drivers/net/wireless/broadcom/b43/main.c
index 39da1a4c30ac..211d6126734f 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -5569,7 +5569,10 @@ static struct b43_wl *b43_wireless_init(struct
b43_bus_dev *dev)
/* fill hw info */
ieee80211_hw_set(hw, RX_INCLUDES_FCS);
ieee80211_hw_set(hw, SIGNAL_DBM);
-
+ if (modparam_nohwcrypt) {
+ printk(KERN_INFO "b43: Setting MFP_CAPABLE\n");
+ ieee80211_hw_set(hw, MFP_CAPABLE);
+ }
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_MESH_POINT) |
In addition, check that the printk message is seen in dmesg.
Larry
Hi, Larry,
On Wed, 20 May 2020 at 21:56, Larry Finger <[email protected]> wrote:
>
> A quick difference - this one supports 3 additional ciphers:
>
> vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:13
> vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:11
> vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:12
Well, yes, I wrote exactly that in the first email. :) But notice
there's another cypher missing from that list…
vedder wpa_supplicant[376]: nl80211: Supported cipher 00-0f-ac:6
… which is CMAC.
> The one with :13 is for BIP-CMAC-256, :11 is BIP-GMAC-128, and :12 is
> BIP-GMAC-256. I did not find a reference that says that these are needed for
> WPA3, but I am suspicious.
Actually, I've been digging around in my other machines, and I noticed
that an Intel card I have, which has no problems connecting to my WPA3
AP, supports a much narrower variety of cyphers. According to iw list,
its supported cyphers are:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CMAC (00-0f-ac:6)
So, the only extra cypher it supports is CMAC. Digging around the web,
I found this [1] blog post, which does seem to imlpy CMAC is necessary
for the group cypher. Additionally, there's this line in the second
log I sent you (with the successful authentication):
vedder wpa_supplicant[376]: WPA: EAPOL-Key MIC using AES-CMAC
(AKM-defined - SAE)
My conclusion is that CMAC mode is required for WPA3 Personal. What
strikes me as odd is b43 not supporting any additional cyphers in
software crypto mode.
With that said, I'm going to try your patch, but I'm 95 % confident
the result will be the same.
Thanks,
Rui
[1] https://mrncciew.com/2019/11/29/wpa3-sae-mode/
Hi again, Larry,
On Thu, 21 May 2020 at 09:35, Rui Salvaterra <[email protected]> wrote:
>
> With that said, I'm going to try your patch, but I'm 95 % confident
> the result will be the same.
Well, I'm glad I was wrong. :) With your second patch, not only MFP is
working in WPA2, but also WPA3. And iw list shows all the cyphers as
supported.
I suggest removing the printk altogether or at least demote it to
b43dbg (b43 seems to have its own printk wrappers). In any case, feel
free to add my
Tested-by: Rui Salvaterra <[email protected]>
Thanks a lot,
Rui
On Thu, 21 May 2020 10:07:38 +0100
Rui Salvaterra <[email protected]> wrote:
> Well, I'm glad I was wrong. :) With your second patch, not only MFP is
> working in WPA2, but also WPA3. And iw list shows all the cyphers as
> supported.
Great. Thank you for testing.
Should we consider defaulting hwcrypto to off?
I wonder what the performance penalty is, if any, on today's CPUs
that have some HW-crypto embedded. Of course that depends on whether we
actually use that here.
Could we have some benchmarks (throughput and CPU load wise)?
--
Michael
Hi, Michael,
On Thu, 21 May 2020 at 11:46, Michael Büsch <[email protected]> wrote:
>
> Great. Thank you for testing.
>
> Should we consider defaulting hwcrypto to off?
IMHO, not without testing. See below. :)
> I wonder what the performance penalty is, if any, on today's CPUs
> that have some HW-crypto embedded. Of course that depends on whether we
> actually use that here.
>
> Could we have some benchmarks (throughput and CPU load wise)?
I'm preparing to do some performance tests as we speak. Nothing too
elaborate, just transferring a file over NFS and having a look at the
CPU usage, with both hardware crypto enabled/disabled (while I
initially thought of doing it over SFTP, the crypto overhead will
surely overwhelm this system). Do you suggest a more scientifically
acceptable test?
Also note that this a PowerPC laptop (iBook G4). This means it's using
the generic C crypto algorithms, there are no SIMD (VMX/AltiVec)
implementations of AES and friends on PowerPC, at least from what I've
seen in the kconfig.
Thanks,
Rui
On Thu, 21 May 2020 12:30:43 +0100
Rui Salvaterra <[email protected]> wrote:
> Also note that this a PowerPC laptop (iBook G4).
That's not exactly a modern CPU, but measurements would be useful
anyway.
--
Michael
On 5/21/20 6:40 AM, Michael B?sch wrote:
> On Thu, 21 May 2020 12:30:43 +0100
> Rui Salvaterra <[email protected]> wrote:
>
>> Also note that this a PowerPC laptop (iBook G4).
>
> That's not exactly a modern CPU, but measurements would be useful
> anyway.
Michael,
Thanks for a hearty morning laugh. I needed the endorphins.
I will be able to run some tests using a BCM4312 on an Intel i7 CPU running at
2.90 GHz. It is a Haswell chip launched is Q3 2013 - a little more modern. My
setup will be using WPA2 connecting to an AC1750 AP.
Larry
On Thu, 21 May 2020 at 12:40, Michael Büsch <[email protected]> wrote:
>
> That's not exactly a modern CPU, but measurements would be useful
> anyway.
It's not exactly a modern Wi-Fi card either, and being 802.11g might
actually help limiting the CPU overhead.
Hi, guys,
On Thu, 21 May 2020 at 15:52, Rui Salvaterra <[email protected]> wrote:
>
> It's not exactly a modern Wi-Fi card either, and being 802.11g might
> actually help limiting the CPU overhead.
Yeah, as I expected, it's neither great nor terrible. I fired up iperf
to do some quick and dirty testing: with WPA2 (hardware crypto) I get
around 13 % CPU, with WPA3 (software crypto), around 34 %. The
throughput is pretty much the same.
Cheers,
Rui
On 5/21/20 11:17 AM, Rui Salvaterra wrote:
> Hi, guys,
>
> On Thu, 21 May 2020 at 15:52, Rui Salvaterra <[email protected]> wrote:
>>
>> It's not exactly a modern Wi-Fi card either, and being 802.11g might
>> actually help limiting the CPU overhead.
>
> Yeah, as I expected, it's neither great nor terrible. I fired up iperf
> to do some quick and dirty testing: with WPA2 (hardware crypto) I get
> around 13 % CPU, with WPA3 (software crypto), around 34 %. The
> throughput is pretty much the same.
I did only a rough test, but turning off hardware encryption increased the b43
interrupt routine from a maximum of 10% of a cpu to about 20%. Even on a fast
cpu, it seems that hw encryption should be used if possible.
I have one additional test for you. With the attached patch, do you get the
message that software crypto is required? It should appear only once.
Larry
On Thu, 21 May 2020 at 20:00, Larry Finger <[email protected]> wrote:
>
> I did only a rough test, but turning off hardware encryption increased the b43
> interrupt routine from a maximum of 10% of a cpu to about 20%. Even on a fast
> cpu, it seems that hw encryption should be used if possible.
I didn't pay attention to the interrupt rate. I wonder if NAPI would help…? :)
> I have one additional test for you. With the attached patch, do you get the
> message that software crypto is required? It should appear only once.
Sure, I'll give it a spin. I'm now compiling the kernel for the laptop
with the other b43 card (BCM4311).
Thanks,
Rui
On Thu, 21 May 2020 at 20:19, Rui Salvaterra <[email protected]> wrote:
>
> Sure, I'll give it a spin. I'm now compiling the kernel for the laptop
> with the other b43 card (BCM4311).
Nope, kmsg is clean. I'm pretty sure the condition is evaluating to
false because we do have the firmware, it's just that the crypto
engine doesn't support the required algo.
Is hardware encryption an all-or-nothing thing in mac80211? Wouldn't
it be possible use the hardware as much as possible and fall back to
software only for the unsupported features? (I guess the answer is
"no, because the firmware gets in the way", but I had to ask.)
On 5/21/20 3:23 PM, Rui Salvaterra wrote:
> On Thu, 21 May 2020 at 20:19, Rui Salvaterra <[email protected]> wrote:
>>
>> Sure, I'll give it a spin. I'm now compiling the kernel for the laptop
>> with the other b43 card (BCM4311).
>
> Nope, kmsg is clean. I'm pretty sure the condition is evaluating to
> false because we do have the firmware, it's just that the crypto
> engine doesn't support the required algo.
> Is hardware encryption an all-or-nothing thing in mac80211? Wouldn't
> it be possible use the hardware as much as possible and fall back to
> software only for the unsupported features? (I guess the answer is
> "no, because the firmware gets in the way", but I had to ask.)
>
My first failure indicates the mac80211 needs to know from the start that
software encryption is to be used. The only places that the driver makes note of
the nohwcrypt is in b43_op_set_key() where it returns -ENOSPC, and our new one
where MFP_CAPABLE is set. Otherwise, the packet flags indicate that encryption
is not needed.
Larry
On Thu, 21 May 2020 16:47:41 -0500
Larry Finger <[email protected]> wrote:
> On 5/21/20 3:23 PM, Rui Salvaterra wrote:
> > On Thu, 21 May 2020 at 20:19, Rui Salvaterra <[email protected]> wrote:
> >>
> >> Sure, I'll give it a spin. I'm now compiling the kernel for the laptop
> >> with the other b43 card (BCM4311).
> >
> > Nope, kmsg is clean. I'm pretty sure the condition is evaluating to
> > false because we do have the firmware, it's just that the crypto
> > engine doesn't support the required algo.
> > Is hardware encryption an all-or-nothing thing in mac80211? Wouldn't
> > it be possible use the hardware as much as possible and fall back to
> > software only for the unsupported features? (I guess the answer is
> > "no, because the firmware gets in the way", but I had to ask.)
> >
>
> My first failure indicates the mac80211 needs to know from the start that
> software encryption is to be used. The only places that the driver makes note of
> the nohwcrypt is in b43_op_set_key() where it returns -ENOSPC, and our new one
> where MFP_CAPABLE is set. Otherwise, the packet flags indicate that encryption
> is not needed.
Thank you all very much for benchmarking this.
As we see, hwcrypto has a major effect on CPU load.
But I'm still in favor of changing the default to nohwcrypt=1.
That would be a trade off between a wifi that does work with "bad"
performance vs. a wifi that does not work at all by default. It would
not stop people from enabling hwcrypto again.
But I'm also wondering, if we can dynamically decide whether to allow
hwcrypto.
Can't we set the MFP-flag all the time and then in b43_op_set_key
decide whether we allow hwcrypto or not? As far as I remember mac80211
falls back to sw-crypto, if an error is returned from the key op. So it
would "just" be a matter of detecting whether MFP is actually being
used in the network we are trying to connect to from within the key op.
Is that information available somewhere in mac80211?
--
Michael
Michael Büsch <[email protected]> writes:
> On Thu, 21 May 2020 16:47:41 -0500
> Larry Finger <[email protected]> wrote:
>
>> On 5/21/20 3:23 PM, Rui Salvaterra wrote:
>> > On Thu, 21 May 2020 at 20:19, Rui Salvaterra <[email protected]> wrote:
>> >>
>> >> Sure, I'll give it a spin. I'm now compiling the kernel for the laptop
>> >> with the other b43 card (BCM4311).
>> >
>> > Nope, kmsg is clean. I'm pretty sure the condition is evaluating to
>> > false because we do have the firmware, it's just that the crypto
>> > engine doesn't support the required algo.
>> > Is hardware encryption an all-or-nothing thing in mac80211? Wouldn't
>> > it be possible use the hardware as much as possible and fall back to
>> > software only for the unsupported features? (I guess the answer is
>> > "no, because the firmware gets in the way", but I had to ask.)
>> >
>>
>> My first failure indicates the mac80211 needs to know from the start that
>> software encryption is to be used. The only places that the driver makes note of
>> the nohwcrypt is in b43_op_set_key() where it returns -ENOSPC, and our new one
>> where MFP_CAPABLE is set. Otherwise, the packet flags indicate that encryption
>> is not needed.
>
>
> Thank you all very much for benchmarking this.
>
> As we see, hwcrypto has a major effect on CPU load.
> But I'm still in favor of changing the default to nohwcrypt=1.
I'm thinking the same.
> That would be a trade off between a wifi that does work with "bad"
> performance vs. a wifi that does not work at all by default.
And did the "bad" performance even have any real visible changes to the
user? IMHO this "bad" performance is small price to pay from getting
WPA3 supported out-of-box, especially when the data throughput is
unaffected.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Hi, Kalle,
On Fri, 22 May 2020 at 12:49, Kalle Valo <[email protected]> wrote:
>
> And did the "bad" performance even have any real visible changes to the
> user? IMHO this "bad" performance is small price to pay from getting
> WPA3 supported out-of-box, especially when the data throughput is
> unaffected.
I agree, I also believe the additional security provided by WPA3 is
more important. The CPU overhead impact exists and is measurable but,
to be honest, I didn't notice any worse performance while browsing the
web, for example (which is already slow enough on a G4 CPU, as you can
imagine).
Thanks,
Rui
On 5/22/20 6:49 AM, Kalle Valo wrote:
>
> And did the "bad" performance even have any real visible changes to the
> user? IMHO this "bad" performance is small price to pay from getting
> WPA3 supported out-of-box, especially when the data throughput is
> unaffected.
Kalle,
The only bad effect is to consume 2-3 times more CPU than used if the firmware
handles encryption. On a modern system, the effect is negligible; however, these
cards are found only on older systems that have uni-processors.
I have reread the mac80211 documentation (comments in code at least), and it
appears that it should be possible to set MFP_CAPABLE unconditionally, and use
the set_key() callback to let mac80211 know if the driver/firmware will handle
encryption. The module parameter could be removed; however, I favor leaving it
in case of broken hardware.
@Rui: I will send you a new patch for testing.
Larry
On 5/22/20 8:46 AM, Rui Salvaterra wrote:
> Hi, Kalle,
>
> On Fri, 22 May 2020 at 12:49, Kalle Valo <[email protected]> wrote:
>>
>> And did the "bad" performance even have any real visible changes to the
>> user? IMHO this "bad" performance is small price to pay from getting
>> WPA3 supported out-of-box, especially when the data throughput is
>> unaffected.
>
> I agree, I also believe the additional security provided by WPA3 is
> more important. The CPU overhead impact exists and is measurable but,
> to be honest, I didn't notice any worse performance while browsing the
> web, for example (which is already slow enough on a G4 CPU, as you can
> imagine).
Rui,
Does this one-line
patch work for WPA3 without setting the nohwcrypt option?
diff --git a/drivers/net/wireless/broadcom/b43/main.c
b/drivers/net/wireless/broadcom/b43/main.c
index 39da1a4c30ac..3ad94dad2d89 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -5569,7 +5569,7 @@ static struct b43_wl *b43_wireless_init(struct b43_bus_dev
*dev)
/* fill hw info */
ieee80211_hw_set(hw, RX_INCLUDES_FCS);
ieee80211_hw_set(hw, SIGNAL_DBM);
-
+ ieee80211_hw_set(hw, MFP_CAPABLE);
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_MESH_POINT) |
Larry
Hi again, Larry,
On Fri, 22 May 2020 at 19:02, Larry Finger <[email protected]> wrote:
>
> Rui,
>
> Does this one-line
> patch work for WPA3 without setting the nohwcrypt option?
>
Interesting. I'm skeptical that it could, yet intrigued that it may
(I'm pretty sure CMAC is a requirement). The patch was mangled, so I
just edited the file manually. Compiling.
Thanks,
Rui
On Fri, 22 May 2020 at 19:02, Larry Finger <[email protected]> wrote:
>
> Rui,
>
> Does this one-line
> patch work for WPA3 without setting the nohwcrypt option?
Ok, so it "works", but I don't know what actually happened (I didn't
do any performance testing yet). I got this relevant output on my
kmsg…
rui@mcnugget:~$ dmesg | awk '(/80211/ || /b43/ || /wlan0/)'
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinux-5.7.0-rc6+
root=UUID=849bbef3-007e-491e-b187-9e259680c2e2 ro mitigations=off
b43.qos=0 b43.verbose=3 usbhid.mousepoll=16 quiet splash
[ 0.035705] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
[ 0.210299] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
found on PCI device 0001:10:12.0
[ 3.361908] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[ 3.454235] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
[ 3.454259] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
8, Version 0
[ 3.485125] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 28.697945] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 28.730381] b43-phy0 debug: Chip initialized
[ 28.731389] b43-phy0 debug: 32-bit DMA initialized
[ 28.731400] b43-phy0 debug: QoS disabled
[ 28.792272] b43-phy0 debug: Wireless interface started
[ 28.820318] b43-phy0 debug: Adding Interface type 2
[ 33.944771] wlan0: authenticate with 04:f0:21:24:28:44
[ 33.970449] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
[ 34.026222] wlan0: authenticate with 04:f0:21:24:28:44
[ 34.026241] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
[ 34.028522] wlan0: authenticated
[ 34.043256] wlan0: associate with 04:f0:21:24:28:44 (try 1/3)
[ 34.046946] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
status=30 aid=1)
[ 34.046964] wlan0: 04:f0:21:24:28:44 rejected association
temporarily; comeback duration 1000 TU (1024 ms)
[ 35.122051] wlan0: associate with 04:f0:21:24:28:44 (try 2/3)
[ 35.125547] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
status=0 aid=1)
[ 35.125808] wlan0: associated
[ 35.268256] b43-phy0 debug: Using hardware based encryption for
keyidx: 0, mac: 04:f0:21:24:28:44
[ 35.268762] b43-phy0 debug: Using hardware based encryption for
keyidx: 2, mac: ff:ff:ff:ff:ff:ff
[ 35.358586] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-22)
[ 35.358977] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 87.283220] wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-22)
[ 87.283521] b43-phy0 debug: Using hardware based encryption for
keyidx: 1, mac: ff:ff:ff:ff:ff:ff
rui@mcnugget:~$
Meanwhile, iw list shows all the possible software cyphers:
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
* CMAC (00-0f-ac:6)
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
What I'm not sure is if b43 is doing all the cyphers it supports in
hardware and falling back to software just for the unsupported ones,
or if it's doing everything in software.
On 5/22/20 3:40 PM, Rui Salvaterra wrote:
> On Fri, 22 May 2020 at 19:02, Larry Finger <[email protected]> wrote:
>>
>> Rui,
>>
>> Does this one-line
>> patch work for WPA3 without setting the nohwcrypt option?
>
> Ok, so it "works", but I don't know what actually happened (I didn't
> do any performance testing yet). I got this relevant output on my
> kmsg…
>
> rui@mcnugget:~$ dmesg | awk '(/80211/ || /b43/ || /wlan0/)'
> [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinux-5.7.0-rc6+
> root=UUID=849bbef3-007e-491e-b187-9e259680c2e2 ro mitigations=off
> b43.qos=0 b43.verbose=3 usbhid.mousepoll=16 quiet splash
> [ 0.035705] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
> [ 0.210299] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
> found on PCI device 0001:10:12.0
> [ 3.361908] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> [ 3.454235] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [ 3.454259] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
> 8, Version 0
> [ 3.485125] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [ 28.697945] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
> [ 28.730381] b43-phy0 debug: Chip initialized
> [ 28.731389] b43-phy0 debug: 32-bit DMA initialized
> [ 28.731400] b43-phy0 debug: QoS disabled
> [ 28.792272] b43-phy0 debug: Wireless interface started
> [ 28.820318] b43-phy0 debug: Adding Interface type 2
> [ 33.944771] wlan0: authenticate with 04:f0:21:24:28:44
> [ 33.970449] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> [ 34.026222] wlan0: authenticate with 04:f0:21:24:28:44
> [ 34.026241] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> [ 34.028522] wlan0: authenticated
> [ 34.043256] wlan0: associate with 04:f0:21:24:28:44 (try 1/3)
> [ 34.046946] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> status=30 aid=1)
> [ 34.046964] wlan0: 04:f0:21:24:28:44 rejected association
> temporarily; comeback duration 1000 TU (1024 ms)
> [ 35.122051] wlan0: associate with 04:f0:21:24:28:44 (try 2/3)
> [ 35.125547] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> status=0 aid=1)
> [ 35.125808] wlan0: associated
> [ 35.268256] b43-phy0 debug: Using hardware based encryption for
> keyidx: 0, mac: 04:f0:21:24:28:44
> [ 35.268762] b43-phy0 debug: Using hardware based encryption for
> keyidx: 2, mac: ff:ff:ff:ff:ff:ff
> [ 35.358586] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-22)
> [ 35.358977] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 87.283220] wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-22)
> [ 87.283521] b43-phy0 debug: Using hardware based encryption for
> keyidx: 1, mac: ff:ff:ff:ff:ff:ff
> rui@mcnugget:~$
>
> Meanwhile, iw list shows all the possible software cyphers:
>
> Supported Ciphers:
> * WEP40 (00-0f-ac:1)
> * WEP104 (00-0f-ac:5)
> * TKIP (00-0f-ac:2)
> * CCMP-128 (00-0f-ac:4)
> * CCMP-256 (00-0f-ac:10)
> * GCMP-128 (00-0f-ac:8)
> * GCMP-256 (00-0f-ac:9)
> * CMAC (00-0f-ac:6)
> * CMAC-256 (00-0f-ac:13)
> * GMAC-128 (00-0f-ac:11)
> * GMAC-256 (00-0f-ac:12)
>
> What I'm not sure is if b43 is doing all the cyphers it supports in
> hardware and falling back to software just for the unsupported ones,
> or if it's doing everything in software.
It will do supported ciphers in hardware, and unsupported using software. The
patch tells mac80211 that we will accept the newer ciphers, then in the
set_key() callback, we tell it whether the current type will be handled in
hardware. Operations will be transparent. I will keep the nohwcrypt option just
in case someone has a hardware malfunction that prohibits hardware use for all
ciphers, but it will not be needed in cases like yours. Performance will be as
you did earlier.
Thanks for testing.
Larry
On Fri, 22 May 2020 at 22:06, Larry Finger <[email protected]> wrote:
>
> It will do supported ciphers in hardware, and unsupported using software. The
> patch tells mac80211 that we will accept the newer ciphers, then in the
> set_key() callback, we tell it whether the current type will be handled in
> hardware. Operations will be transparent. I will keep the nohwcrypt option just
> in case someone has a hardware malfunction that prohibits hardware use for all
> ciphers, but it will not be needed in cases like yours. Performance will be as
> you did earlier.
Wonderful, I didn't know mac80211 was that smart. But I have even
better news (and it would be great if someone else could verify this):
with your unconditional enablement of MFP, the CPU overhead of WPA3 is
on par with WPA2, I believe it's doing hardware crypto. And it makes
sense when you think of it, WPA3 Personal uses the same AES cypher as
WPA2, but with SAE handshake, if I'm not mistaken.
> Thanks for testing.
My pleasure!
Rui
On Fri, 22 May 2020 at 23:06, Larry Finger <[email protected]> wrote:
> On 5/22/20 3:40 PM, Rui Salvaterra wrote:
> > On Fri, 22 May 2020 at 19:02, Larry Finger <[email protected]> wrote:
> >>
> >> Rui,
> >>
> >> Does this one-line
> >> patch work for WPA3 without setting the nohwcrypt option?
> >
> > Ok, so it "works", but I don't know what actually happened (I didn't
> > do any performance testing yet). I got this relevant output on my
> > kmsg…
> >
> > rui@mcnugget:~$ dmesg | awk '(/80211/ || /b43/ || /wlan0/)'
> > [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinux-5.7.0-rc6+
> > root=UUID=849bbef3-007e-491e-b187-9e259680c2e2 ro mitigations=off
> > b43.qos=0 b43.verbose=3 usbhid.mousepoll=16 quiet splash
> > [ 0.035705] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
> > [ 0.210299] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
> > found on PCI device 0001:10:12.0
> > [ 3.361908] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> > [ 3.454235] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> > [ 3.454259] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
> > 8, Version 0
> > [ 3.485125] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > [ 28.697945] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
> > [ 28.730381] b43-phy0 debug: Chip initialized
> > [ 28.731389] b43-phy0 debug: 32-bit DMA initialized
> > [ 28.731400] b43-phy0 debug: QoS disabled
> > [ 28.792272] b43-phy0 debug: Wireless interface started
> > [ 28.820318] b43-phy0 debug: Adding Interface type 2
> > [ 33.944771] wlan0: authenticate with 04:f0:21:24:28:44
> > [ 33.970449] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> > [ 34.026222] wlan0: authenticate with 04:f0:21:24:28:44
> > [ 34.026241] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> > [ 34.028522] wlan0: authenticated
> > [ 34.043256] wlan0: associate with 04:f0:21:24:28:44 (try 1/3)
> > [ 34.046946] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> > status=30 aid=1)
> > [ 34.046964] wlan0: 04:f0:21:24:28:44 rejected association
> > temporarily; comeback duration 1000 TU (1024 ms)
> > [ 35.122051] wlan0: associate with 04:f0:21:24:28:44 (try 2/3)
> > [ 35.125547] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> > status=0 aid=1)
> > [ 35.125808] wlan0: associated
> > [ 35.268256] b43-phy0 debug: Using hardware based encryption for
> > keyidx: 0, mac: 04:f0:21:24:28:44
> > [ 35.268762] b43-phy0 debug: Using hardware based encryption for
> > keyidx: 2, mac: ff:ff:ff:ff:ff:ff
> > [ 35.358586] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-22)
> > [ 35.358977] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > [ 87.283220] wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-22)
> > [ 87.283521] b43-phy0 debug: Using hardware based encryption for
> > keyidx: 1, mac: ff:ff:ff:ff:ff:ff
> > rui@mcnugget:~$
> >
> > Meanwhile, iw list shows all the possible software cyphers:
> >
> > Supported Ciphers:
> > * WEP40 (00-0f-ac:1)
> > * WEP104 (00-0f-ac:5)
> > * TKIP (00-0f-ac:2)
> > * CCMP-128 (00-0f-ac:4)
> > * CCMP-256 (00-0f-ac:10)
> > * GCMP-128 (00-0f-ac:8)
> > * GCMP-256 (00-0f-ac:9)
> > * CMAC (00-0f-ac:6)
> > * CMAC-256 (00-0f-ac:13)
> > * GMAC-128 (00-0f-ac:11)
> > * GMAC-256 (00-0f-ac:12)
> >
> > What I'm not sure is if b43 is doing all the cyphers it supports in
> > hardware and falling back to software just for the unsupported ones,
> > or if it's doing everything in software.
> It will do supported ciphers in hardware, and unsupported using software. The
> patch tells mac80211 that we will accept the newer ciphers, then in the
> set_key() callback, we tell it whether the current type will be handled in
> hardware. Operations will be transparent. I will keep the nohwcrypt option just
> in case someone has a hardware malfunction that prohibits hardware use for all
> ciphers, but it will not be needed in cases like yours. Performance will be as
> you did earlier.
Nice work Larry, thank you!
--
Rafał
Rafał Miłecki <[email protected]> writes:
> On Fri, 22 May 2020 at 23:06, Larry Finger <[email protected]> wrote:
>> On 5/22/20 3:40 PM, Rui Salvaterra wrote:
>> > On Fri, 22 May 2020 at 19:02, Larry Finger <[email protected]> wrote:
>> >>
>> >> Rui,
>> >>
>> >> Does this one-line
>> >> patch work for WPA3 without setting the nohwcrypt option?
>> >
>> > Ok, so it "works", but I don't know what actually happened (I didn't
>> > do any performance testing yet). I got this relevant output on my
>> > kmsg…
>> >
>> > rui@mcnugget:~$ dmesg | awk '(/80211/ || /b43/ || /wlan0/)'
>> > [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinux-5.7.0-rc6+
>> > root=UUID=849bbef3-007e-491e-b187-9e259680c2e2 ro mitigations=off
>> > b43.qos=0 b43.verbose=3 usbhid.mousepoll=16 quiet splash
>> > [ 0.035705] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
>> > [ 0.210299] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
>> > found on PCI device 0001:10:12.0
>> > [ 3.361908] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> > [ 3.454235] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> > [ 3.454259] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
>> > 8, Version 0
>> > [ 3.485125] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>> > [ 28.697945] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
>> > [ 28.730381] b43-phy0 debug: Chip initialized
>> > [ 28.731389] b43-phy0 debug: 32-bit DMA initialized
>> > [ 28.731400] b43-phy0 debug: QoS disabled
>> > [ 28.792272] b43-phy0 debug: Wireless interface started
>> > [ 28.820318] b43-phy0 debug: Adding Interface type 2
>> > [ 33.944771] wlan0: authenticate with 04:f0:21:24:28:44
>> > [ 33.970449] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
>> > [ 34.026222] wlan0: authenticate with 04:f0:21:24:28:44
>> > [ 34.026241] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
>> > [ 34.028522] wlan0: authenticated
>> > [ 34.043256] wlan0: associate with 04:f0:21:24:28:44 (try 1/3)
>> > [ 34.046946] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
>> > status=30 aid=1)
>> > [ 34.046964] wlan0: 04:f0:21:24:28:44 rejected association
>> > temporarily; comeback duration 1000 TU (1024 ms)
>> > [ 35.122051] wlan0: associate with 04:f0:21:24:28:44 (try 2/3)
>> > [ 35.125547] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
>> > status=0 aid=1)
>> > [ 35.125808] wlan0: associated
>> > [ 35.268256] b43-phy0 debug: Using hardware based encryption for
>> > keyidx: 0, mac: 04:f0:21:24:28:44
>> > [ 35.268762] b43-phy0 debug: Using hardware based encryption for
>> > keyidx: 2, mac: ff:ff:ff:ff:ff:ff
>> > [ 35.358586] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-22)
>> > [ 35.358977] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> > [ 87.283220] wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-22)
>> > [ 87.283521] b43-phy0 debug: Using hardware based encryption for
>> > keyidx: 1, mac: ff:ff:ff:ff:ff:ff
>> > rui@mcnugget:~$
>> >
>> > Meanwhile, iw list shows all the possible software cyphers:
>> >
>> > Supported Ciphers:
>> > * WEP40 (00-0f-ac:1)
>> > * WEP104 (00-0f-ac:5)
>> > * TKIP (00-0f-ac:2)
>> > * CCMP-128 (00-0f-ac:4)
>> > * CCMP-256 (00-0f-ac:10)
>> > * GCMP-128 (00-0f-ac:8)
>> > * GCMP-256 (00-0f-ac:9)
>> > * CMAC (00-0f-ac:6)
>> > * CMAC-256 (00-0f-ac:13)
>> > * GMAC-128 (00-0f-ac:11)
>> > * GMAC-256 (00-0f-ac:12)
>> >
>> > What I'm not sure is if b43 is doing all the cyphers it supports in
>> > hardware and falling back to software just for the unsupported ones,
>> > or if it's doing everything in software.
>>
>> It will do supported ciphers in hardware, and unsupported using software. The
>> patch tells mac80211 that we will accept the newer ciphers, then in the
>> set_key() callback, we tell it whether the current type will be handled in
>> hardware. Operations will be transparent. I will keep the nohwcrypt option just
>> in case someone has a hardware malfunction that prohibits hardware use for all
>> ciphers, but it will not be needed in cases like yours. Performance will be as
>> you did earlier.
>
> Nice work Larry, thank you!
Indeed, this is a perfect solution.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches