Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

From: Arend van Spriel
Date: Sun Dec 24 2023 - 04:03:28 EST


On 12/22/2023 1:03 AM, Neal Gompa wrote:
On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:

Hi Julian,

Using the WSEC command instead of sae_password seems to be the supported
mechanism on newer firmware, and also how the brcmdhd driver does it.

According to user reports [1], the sae_password codepath doesn't actually
work on machines with Cypress chips anyway, so no harm in removing it.

This makes WPA3 work with iwd, or with wpa_supplicant pending a support
patchset [2].

[1] https://rachelbythebay.com/w/2023/11/06/wpa3/
[2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html

Signed-off-by: Hector Martin <marcan@xxxxxxxxx>
Reviewed-by: Neal Gompa <neal@xxxxxxxxx>

Arend, what do you think?

We recently talked about people testing brcmfmac patches, has anyone else
tested this?

Not sure I already replied so maybe I am repeating myself. I would prefer
to keep the Cypress sae_password path as well although it reportedly does
not work. The vendor support in the driver can be used to accommodate for
that. The other option would be to have people with Cypress chipset test
this patch. If that works for both we can consider dropping the
sae_password path.

Regards,
Arend

So, if nobody from Cypress chimes in ever, and nobody cares nor tests
Cypress chipsets, are we keeping any and all existing Cypress code-paths
as bitrotting code forever and adding gratuitous conditionals every time
any functionality needs to change "just in case it breaks Cypress" even
though it has been tested compatible on Broadcom chipsets/firmware?

Because that's not sustainable long term.

You should look into WEXT just for the fun of it. If it were up to me
and a bunch of other people that would have been gone decades ago. Maybe
a bad example if the sae_password is indeed not working, but the Cypress
chipset is used in RPi3 and RPi4 so there must be a couple of users.

There are reports that WPA3 is broken on the Cypress chipsets the
Raspberry Pis are using and this patch fixes it:
https://rachelbythebay.com/w/2023/11/06/wpa3/

Based on that, it appears that all known users of WPA3 capable
hardware with this driver require this fix.

the Pis are all using an outdated firmware. In their distro they put the
firmware already under the alternates systems, but it just lacks the SAE
offload support that is required to make WPA3 work. The linux-firmware
version does the trick nicely.

I documented what I did to make this work on Pi5 (note that I normally
use Fedora on Pi4 and thus never encountered this issue)

https://holtmann.dev/enabling-wpa3-on-raspberry-pi/

However you need to use iwd and not hope that you get a wpa_supplicant
released version that will work.

So whole game of wpa_supplicant is vendor specific to the company that
provides the driver is also insane, but that is another story. Use iwd
and you can most likely have WPA3 support if you have the right firmware.


wpa_supplicant is perfectly fine if the necessary patches are
backported, as Fedora has done:
https://src.fedoraproject.org/rpms/wpa_supplicant/c/99f4bf2096d3976cee01c499d7a30c1376f5f0f7

The brcmfmac firmware has its own 802.11 stack implementation and as such it has a SME running in firmware which means the driver only implements the NL80211_CMD_CONNECT primitive. Now if the firmware also has in-driver supplicant (*-idsup-*) supporting SAE (*-sae-*) it can be offloaded. That is what Cypress went with at least for upstream. For firmware without these in the firmware target string the driver needs to implement support for NL80211_CMD_EXTERNAL_AUTH, which is what we opted for in Broadcom BCA (or WCC-Access as we call it these days). So I don't think it is a fair assessment to call the wpa_supplicant implementation vendor specific.

Regards,
Arend

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature