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, ArendSo, 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
