Wi-Fi Protected Access 3 (WPA3) support

[ghost]

I bought a Raspberry Pi Zero 2 W and apparently it does not support my home wifi which uses WPA3.

I excepted that to be the case, since on Debian usually works just fine, and this device is a new release.

It should be at last officialy stated somewhere that is not supported. I basically bought something I can't use.

Notice that WPA3 is not anymore a theory, many commercial routers now ship with it in mixed mode or add that through firmware update.

Side note: actually run just fine on common operating systems from Windows to Android, including Linux if you have no firmware issues.

[paulfertser]

For the reference, wpa_supplicant support has already been offered for upstream: https://lists.infradead.org/pipermail/hostap/2023-July/041653.html . Probably you can help test and review that?

iwd upstream supports it for years so if one wants WPA3 Personal now it's just a matter of installing and configuring iwd instead of wpa_supplicant.

[0d0a]

That patch is not compatible with the latest pi kernel the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 21 Nov 2023, at 20:36, Paul Fertser @.***> wrote: For the reference, wpa_supplicant support has already been offered for upstream: https://lists.infradead.org/pipermail/hostap/2023-July/041653.html . Probably you can help test and review that?

iwd upstream supports it for years so if one wants WPA3 Personal now it's just a matter of installing and configuring iwd instead of wpa_supplicant.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[paulfertser]

On Tue, Nov 21, 2023 at 11:52:46AM -0800, 0d0a wrote:

That patch is not compatible with the latest pi kernel

This patch is to wpa_supplicant, not to the kernel. So it can not be incompatible.

WPA3 Personal is supported by mainline Linux, the kernel, for few years. And that includes the kernels that run an raspberrypi boards.

Anyway you do not really need wpa_supplicant, use iwd instead and then WPA3 will work for you without additional tweaks (provided you use suitable firmware for the wifi module).

[schildbach]

I recently installed Raspberry Pi OS on a Pi Zero 2W and it installed wpa_supplicant by default, with no instructions on how to switch to iwd. I tried doing that but failed.

[herrernst]

Is the suitable firmware in Raspberry Pi OS repos? I am still using RPi OS 10, I see no sae:

$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n 2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60 DVID 01-9b7a7032

But in this post I see sae. If for newer Raspberry Pi OS version it's just a matter of using iwd I take back my flame ;-)

[paulfertser]

On Tue, Nov 21, 2023 at 12:17:16PM -0800, herrernst wrote:

Is the suitable firmware in Raspberry Pi OS repos? I am still using RPi OS 10, I see no sae:

$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n 2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60 DVID 01-9b7a7032

That's good way to check. Since it's not there just download from git.kernel.org firmware repository, the binary hosted there has sae enabled.

Why "Raspberry Pi OS" maintainers ship some other firmware version is probably material for another ticket.

But in [1]this post I see sae. If for newer Raspberry Pi OS version it's just a matter of using iwd I take back my flame ;-)

Apparently you also need to manually replace the firmware binary and reboot. The git.kernel.org repository is the official "upstream" for firmwares to be used with Linux.

[herrernst]

Unfortunately, on Raspberry Pi OS 12 it's still the same firmware (1043.2164 FWID 01-703fd60). I don't like manually downloading a file and replacing a file provided by the distribution, that eventually leads to chaos and instability. I think it's the duty of Raspberry Pi Ltd (or Foundation) to provide an OS with current firmware. I have opened a ticket at the corresponding repo: https://github.com/RPi-Distro/firmware-nonfree/issues/41 @Arseney300: Where did you get your package, which OS are you using? Which version is it? Mine is 1:20230210-5+rpt2.

[Arseney300]

@herrernst I installed OS on my rpi a long time ago, and I'm not sure where i got the image, but i think i got it from official debian repo (version for aarch64) my "uname -a": Linux arseniy-rpi 5.10.0-8-arm64 #1 SMP Debian 5.10.46-2 (2021-07-20) aarch64 GNU/Linux) and i think i get firmware package from debian repo too, my current version is "20210315-2"

[sk8board]

Here is a pull request from two years ago which is titled Update CYW43455 to 7.45.234 (which supports WPA3-SAE), but they went with a version that does not support WPA3-SAE, 7.45.231.

Maybe the original Pull Request needs to be reopened?

FYI: Here is the location of the CYW43455 firmware for Raspberry Pi OS. https://github.com/RPi-Distro/firmware-nonfree/tree/bookworm/debian/config/brcm80211/cypress

[herrernst]

Here is a pull request from two years ago which is titled Update CYW43455 to 7.45.234 (which supports WPA3-SAE), but they went with a version that does not support WPA3-SAE, 7.45.231.

That pull request was closed, not merged, but after reading this comment it seems they merged (without a MR) a trial version .241, probably in https://github.com/RPi-Distro/firmware-nonfree/commit/dc406650e840705957f8403efeacf71d2d7543b3

[macmpi]

Now 43455 (Pi 3+, 4, 5) WPA3 support is in latest 1:20230210-5+rpt3 firmware package, do we have an outlook for other onboard wifi devices (Pi 3, ZeroW, Zero2) with 43430/6 derivatives (and 43456 for Pi 4cm)?

[madkiss]

FWIW, I was not able to get SAE working with iwd on a freshly installed RPi 5. I do see the SAE entries in "iw phy", but the supplied iwd version will refuse to start an actual AP on wlan0 and NetworkManager will claim that wlan0 is "unsuitable".

[paulfertser]

FWIW, I was not able to get SAE working with iwd on a freshly installed RPi 5.

Do you mean in AP mode or in regular STA mode?

I gave SAE AP a quick try with hostapd on another board with Ampack AP6255 (BCM4345/6) and I clearly saw hostapd not complaining and the AP actually beaconing but I couldn't connect to it (unsure why, I used someone else's android tablet and it didn't provide any details about how exactly it failed).

Other AP-related observations testiing WPA2 were "enabling mandatory 802.11w prevents AP from starting (a message about mismatching parameters is emitted to dmesg), making it optional produces no errors but the AP didn't beacon".

[madkiss]

Sorry for the confusion, I was trying AP mode I think, following https://rachelbythebay.com/w/2024/01/24/wpa3/

[iustin]

I think it was already mentioned that WPA3 support is for station mode only (not entirely sure).

[madkiss]

What a bummer. I actually even bought a USB WiFi dongle with an mt chip to do an SAE AP on the Pi. Sorry for the fuzz however.

[paulfertser]

Sorry for the confusion, I was trying AP mode I think, following https://rachelbythebay.com/w/2024/01/24/wpa3/

But this blog post doesn't mention AP mode at all (only the reported capability) :)

Are you normally using RPi as an AP?

[madkiss]

I only noticed that now. My bad. And no, this is for a mobile setup to create wifi networks while on the road.

[paulfertser]

Yes, AP mode isn't supposed to work for SAE currently with any known software. It's supposed that hostapd should be adding NL80211_ATTR_SAE_PASSWORD attribute to NL80211_CMD_START_AP but that's not implemented in upstream.

It's hard to tell without testing if the mainline kernel is doing the right thing or there's some tiny piece missing but you can give it a try with these hostapd patches [0][1] and probably the others from that directory in the right sequence applied to the right version.

[0] https://github.com/digi-embedded/meta-digi/blob/kirkstone/meta-digi-dey/recipes-connectivity/hostapd/hostapd/murata/0011-SAE-Support-SAE-authentication-offload-in-AP-mode.patch [1] https://github.com/digi-embedded/meta-digi/blob/kirkstone/meta-digi-dey/recipes-connectivity/hostapd/hostapd/murata/0010-nl80211-Support-SAE-authentication-offload-in-AP-mod.patch

[madkiss]

Thank you. AIUI hostap does have most of these patches in 2.10 already. I'll try to allocate some time and fiddle with it :)

[paulfertser]

Do not bother with those old hostapd patches, I see current git HEAD already has everything essential included, both for client and for AP modes. Apparently it'll be part of 2.11 (so you need to build from git for now). That said, in my quick testing a client wasn't able to connect to a SAE AP run by AP6255 brcmfmac module but probably my methodology had an issue and you'll have better luck.

[madkiss]

So I did some tests over the weekend. I updated the RPi to 6.6 and even applied some additional brcmfmac-patches that had since been published. I created new packages from hostapd-HEAD. Without any luck, though: I can see the SAE wifi that hostapd created, but I cannot connect to it, hostapd doesn't produce any valuable logging output and the connection to the AP fails. I do see these lines in dmesg though:

[ 454.530190] ieee80211 phy0: brcmf_set_wsec: failed to change PSK in firmware (len=0) [ 517.474148] ieee80211 phy0: brcmf_set_wsec: failed to change PSK in firmware (len=0) [ 698.242216] ieee80211 phy0: brcmf_set_wsec: failed to change PSK in firmware (len=0) [ 1005.570394] ieee80211 phy0: brcmf_set_wsec: failed to change PSK in firmware (len=0)

[paulfertser]

I can see the SAE wifi that hostapd created, but I cannot connect to it, hostapd doesn't produce any valuable logging output and the connection to the AP fails

Matches my tests :/

[ 454.530190] ieee80211 phy0: brcmf_set_wsec: failed to change PSK in firmware (len=0)

So you're trying patches from Asahi devs too, OK. My tests show that this method doesn't work with our firmware, even for client mode.

[madkiss]

Not knowingly with regards to Asahi. I am using whatever is in 6.6+HEAD and 2.10+HEAD hostapd-wise.

[jebanon]

It's interesting to compare the configuration from two different firmware versions. v7.45.234 (years old) supports SAE on-chip as evidenced by the presence of sae, idsup, an idauth:

#> strings cyfmac43455-sdio.prd_7.45.234.bin | tail -n2
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2
DVID 01-1fda2915

Looking at the latest firmware release from infineon (v7.45.265), they have explicitly removed those flags, and replaced them with extsae. The intent is that now a userspace application (they only officially support wpa-supplicant), shall handle the SAE handshake instead of the chip doing it:

#> strings cyfmac43455-sdio.prd_7.45.265.bin | tail -n2
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-extsae-dpp-sr-okc-bpd Version: 7.45.265 (28bca26 CY) CRC: 68bafb8c Date: Tue 2023-08-29 01:51:02 PDT Ucode Ver: 1043.2170 FWID 01-b677b91b
DVID 01-16dd0023

So, IWD, works with (rather old) firmware because that old firmware does run SAE on the chip. IWD does NOT (in my testing) work correctly with WPA3 neworks if you attempt to use the newest firmware. Even if you explicitly prevent offloading support for SAE, FWSUP, and FWAUTH in the brcmfmac.conf file, iwd will not work.

Has anybody found a way to make iwd work with a modern firmware binary? It seems odd that the only two options are:

1. Use iwd with old firmware
2. Use patched wpa-supplicant with new firmware

[paulfertser]

 1. Use iwd with old firmware  2. Use patched wpa-supplicant with new firmware

The upcoming wpa_supplicant version 2.11 will also include support for "old firmware" (SAE_OFFLOAD extended feature).

And in general it looks like having firmware handle SAE is what current Broadcom does (judging by firmware from macOS and bcmdhd out of tree kernel driver used by many android devices).

BTW, have you found anything that's better with the "new firmware" compared to the old?

[jebanon]

And in general it looks like having firmware handle SAE is what current Broadcom does (judging by firmware from macOS and bcmdhd out of tree kernel driver used by many android devices).

Seems like they did the opposite in this case. Used to offload it to the chip firmware, but now do not. I have reached out to infineon to understand why, but they haven't answered this question yet.

BTW, have you found anything that's better with the "new firmware" compared to the old?

Nothing concrete. Anecdotally, I think Bluetooth coexistance and roaming is better on the new firmware, and I also used to see issues with the driver ocassionally crashing under heavy load, but it is has been hard to disambiguate what is caused by brcm driver changes, and what is a result of the firmware. I'm not the only one with this question. Consistently, when infineon posts a new FMAC release, they share a list of "fixes" but are never clear on what is being fixed by firmware, driver, or some combination. For example, see this comment on the september 2023 release where they provided the latest firmware for the 43455 (7.45.265).

[jebanon]

Infineon confirmed to me that they removed offload SAE support because they ran out of memory for other changes on the chip. I asked them about putting in back on instead of some other features, or providing a few varieties of the firmware that would support different options. They said that they will not do that. I also asked about supporting IWD for the user-space SAE R3 implementation. They also said no, and that they will only support wpa-supplicant, which apparently supports this natively now in the newest version.

So for now, the options are:

1. Use IWD with v.234 of the firmware (what is in the latest repo: https://github.com/RPi-Distro/firmware-nonfree/commit/ad23f33a29fb7f8bc344d80d0eb40abe1953d145)
2. Use wpa-supplicant with newer firmware with the SAE_OFFLOAD feature disabled in the brcm config file (to tell the userspace app to not attempt offloading onto the chip)

In the future, using IWD with the latest firmware might be possible, if it can be configured to support however the infineon chipset handles this. I have no idea what would be required to enable that.

[kwinz]

@jebanon Could you give me an idea how big the impact of SAE_OFFLOAD is? AFAIK SAE is only used during association / authentication. So missing SAE_OFFLOAD could result in slightly slower or less energy efficient connection to APs but presumably wouldn't have an impact on throughput, latency, jitter - correct?

[jebanon]

@jebanon Could you give me an idea how big the impact of SAE_OFFLOAD is? AFAIK SAE is only used during association / authentication. So missing SAE_OFFLOAD could result in slightly slower or less energy efficient connection to APs but presumably wouldn't have an impact on throughput, latency, jitter - correct?

I haven't quantified it, but I'm doubtful that it has any meaningful performance impact when in station mode, as you've noted. For my own usage, I certainly don't care about whether the userspace network manager is doing it (iwd or wpa-supplicant), or whether it is happening on the chip firmware. If infineon wants to move towards the userspace software handling the SAE handshake, that is fine with me - the bummer is just that however they have accomplished that (at least for now), doesn't appear to work with iwd in my testing. That means iwd users are stuck on very chip firmware (and that raspberry pi is "shipping" old firmware that is probably missing newer security fixes, features, etc).

[pelwell]

FYI I'm working on a minimal set of downstream driver patches that add support for the SAE_EXT feature using wpa_supllicant on as many of our devices as possible, at which point we'll be able to update to the latest firmwares. Two or three patches is sufficient for the 43455, but it's not working on the Synaptics-sourced devices yet.

[jebanon]

@pelwell my understanding from infineon was that the latest upstream wpa-supplicant "just works" (have not confirmed) with the latest downstream drivers from infineon (these). Is that not the case? I was under the impression that the SAE_EXT support was already in there and worked with the new firmware, and with wpa-supplicant, but just doesn't work with iwd.

[pelwell]

214 patches is not minimal.

[pelwell]

PR #5945 is the three-patch set required to get WPA3 working with our current wpa_supplicant on Pi 5, Pi 4 and CM4. Whether we can also get it working on Pi 400 and Pi Zero 2 W is the subject of an open support ticket with Synaptics.

[0d0a]

Does not work in so-called mixed mode on pi4 fresh is install bookworm 64bits,  followed by sudo rpi-update pulls/5945the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 12 Feb 2024, at 17:51, Phil Elwell @.***> wrote: PR #5945 is the three-patch set required to get WPA3 working with our current wpa_supplicant on Pi 5, Pi 4 and CM4. Whether we can also get it working on Pi 400 and Pi Zero 2 W is the subject of an open support ticket with Synaptics.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[pelwell]

Does not work in so-called mixed mode on pi4 fresh is install bookworm 64bits

That's not a great bug report:

1. What is "mixed mode"?
2. What did you do?
3. What did you expect to happen?
4. What actually happened?
5. On which software did this last work?

[0d0a]

Mixed mode is when the Wi-Fi router I connect to has the same name for 2.4 GHZ and five ghz and wpa2/wpa3 mode both on. Router is a fritzbox 7590 latest os 7.57As written in  original post installed a fresh bookworm 64 bits on a pi 4 . Applied the rip-update as mentioned in this message chain.Expexted The system to connect to wpa3 5ghz.the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 13 Feb 2024, at 09:56, Phil Elwell @.***> wrote:

Does not work in so-called mixed mode on pi4 fresh is install bookworm 64bits

That's not a great bug report:

What is "mixed mode"? What did you do? What did you expect to happen? What actually happened? On which software did this last work?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[pelwell]

And:

On which software did this last work?

i.e. is this a regression compared to the current sae firmware+ iwd solution?

[0d0a]

Never worked the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 13 Feb 2024, at 12:28, Phil Elwell @.***> wrote: And:

On which software did this last work?

i.e. is this a regression compared to the current sae firmware+ iwd solution?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[jebanon]

@paulfertser Following back up on this question:

BTW, have you found anything that's better with the "new firmware" compared to the old?

I have now confirmed empirically: BLE pairing connections fail more often on the older (v.234) firmware. BLE connections succeed on the first try consistently when on the newer (v.265) firmware, with all other variables unchanged. On the older firmware, it sometimes takes a few tries to get the initial connection to work.

[paulfertser]

I have now confirmed empirically: BLE pairing connections fail more often on the older (v.234) firmware. BLE connections succeed on the first try consistently when on the newer (v.265) firmware, with all other variables unchanged. On the older firmware, it sometimes takes a few tries to get the initial connection to work.

Good to know, thank you for sharing! Probably BT coex is better implemented or configured there somehow and it also affects e.g. BT headphones while doing heavy WiFi traffic?

[jebanon]

BT headphones while doing heavy WiFi traffic?

Probably some coexistence tuning, as you've noted, so yes, I would assume it impacts BT Classic too, but I can't say for certain. I only validated BLE. There are different tuning parameters for BT Classic vs BLE in the NVRAM, so I don't know exactly how their handling of the two differs in the firmware.

[BroJac5246]

+1

My Wi-Fi network has a WPA2 'regular' SSID and a WPA3 'secure' SSID. I only want NAS servers, etc. connected to the secure network. A Raspberry Pi makes for a great NAS server, but I don't want it on the less secure network.

[gearhead]

Been playing with this in May 2024. on a Pi of flavors which have 5Ghz capability (3b+,4,5), none can advertise or connect to a functional WPA3/SAE protected network. Tried hostapd: It advertises but does not allow any connection wpa_supplicant: will not connect to an SAE/WPA3 network that works fine for my phone. iwd: same as wpa_supplicant.

The current (3 year old) driver/firmware advertises that it does:

#dmesg | grep brcmfmac
[   65.711481] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   65.725459] usbcore: registered new interface driver brcmfmac
[   66.080302] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[   66.080811] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2

#iw list 
...
    Supported extended features:
        * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
        * [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
        * [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode
        * [ DFS_OFFLOAD ]: DFS offload
        * [ SAE_OFFLOAD ]: SAE offload support
        * [ 4WAY_HANDSHAKE_AP_PSK ]: AP mode PSK offload support
        * [ SAE_OFFLOAD_AP ]: AP mode SAE authentication offload support

This is with RPiOS Bookworm updated and running this kernel:

# uname -a
Linux rpi64 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

What is stopping functionality other than it is a brcmfmac card.