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.

[pelwell]

Which AP is this that doesn't support WPA2? It seems a bit premature.

[kroon040]

Is wpa3 possible with debian bullseye with Pi zero w2?

[pelwell]

No Raspberry Pi currently supports WPA3.

[kroon040]

So the RPI 3 and 4 supports WPA3 and the RPI Zero 2 not?

[JamesH65]

"No Raspberry Pi supports WPA3"

As in, none of the Raspberry Pi's with wireless support WPA3.

[jfargen]

@JamesH65 is this because wpa_supplicant version which supports WPA3 is 2:2.9-4, but the wpa_supplicant version available on Raspberry Pi 10.11 is 2.8-devel. Or will it require a kernel driver update from Broadcom? Or a new Wifi chipset?

[JamesH65]

I believe it will need at minimum new firmware, quite possibly a new chip.

[JsBergbau]

According to https://forum.openwrt.org/t/wpa3-support-in-openwrt/10554/144 there is no special hardware support needed for WPA3 with OpenWRT devices.
So when you can create an access point with WPA3 encryption in software, than it should also be possible to implement the client solely in software.
Would also be very glad when Raspberry PI Zero W and Zero 2W support WPA3.

[somerando905]

Connecting to a WPA3-Personal network works fine for me with a Pi 3 Model B when I use iwd. I recently bought a Pi Zero 2 W thinking it would behave similarly since supposedly the wifi hardware is almost identical, but unfortunately that's not the case. Same kernel/driver, same network, but it fails to connect.

iw reports support for the SAE_OFFLOAD extended feature among other things on the 3b, not on the 02w though. So that's one obvious difference. Looking at the brcmfmac driver, it seems that that feature flag gets set if the firmware claims support.

The 02w wifi firmware then looks rather "beta" to me, going by the version string:

BCM43430/2 wl0: Oct  9 2020 14:44:32 version 9.88.4.65 (test) (f149b32@shgit)  (r679549) FWID 01-f40f3270

I suppose it's incomplete? Are there any plans to release an updated firmware in the foreseeable future?

[jetflux]

Why can't the raspberry pi broadcom wifi chips support WPA3 ?!?
I Tried many wifi dongles from cheapest realtek to atheros and such with wpa_supplicant 2.9+ they all work with WPA3, but broadcom raspberry pi's dont. I hope the new raspberry pi's comming will dump broadcom for something better....

[somerando905]

Are there any plans to release an updated firmware in the foreseeable future?

I take the lack of a response to mean "no."

That's too bad. But I noticed there are commits in the firmware repo referencing a new Zero 2 W revision with a different wifi chipset. Hope you get those wifi issues sorted out, it's a nice device otherwise. Cheers

[schildbach]

I'm also longing for my Raspi Zero 2 W to support WPA3. I thought that's a matter of course these days.

[taylorkline]

No issue on my end:

/etc/wpa_supplicant/wpa_supplicant.conf:

update_config=1

network={
 ssid="ssid"
 key_mgmt=WPA-PSK-SHA256
 psk=psk
 ieee80211w=2
}

[jeffsf]

Fails on a mixed WPA2/WPA3 or a pure WAP3 network against OpenWrt HEAD as of late May 2022. hostapd reports

Mon Jun 13 12:49:46 2022 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH e4:5f:01:aa:bb:cc

repeatedly. AP does not have any issues with macOS or iOS devices on the same VAP.

[BennyE]

@taylorkline - This configuration example is a step in the right direction, but it is not WPA3-Personal. WPA3-Personal uses Simultaneous Authentication of Equals (SAE) as key_mgmt and requires Protected Management Frames (PMF) aka Management Frame Protection (MFP) as in your example (PMF/MFP is standardised via IEEE 802.11w and mandatory in Wi-Fi 6 certification (as WPA3 is mandatory, which requires 802.11w support)). Thanks for sharing!

In my opinion, 802.11w is one of the most important elements to secure the network (clients) against DoS-type attacks (de-assoc/de-auth-attack) - often ESP32-based as previously mentioned in this (or other) threads. (This is also what I tell my partners/customers)

Here is a (validated) WPA3 configuration for wpa_supplicant:

network={
    disabled=0
    ssid="WPA3"
    proto=RSN
    key_mgmt=SAE
    sae_password="very-secure-P4ssw0rd!"
    ieee80211w=2
}

@JamesH65

I believe it will need at minimum new firmware, quite possibly a new chip.

Fortunately it (often) doesn't require new hardware, at least not for Pi3B+/Pi4. I haven't tried on Pi Zero - subject to be tested.

Infineon (Ex-Broadcom => Ex-Cypress) issues patches against 5.10.9 on their website/community:
https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2022-05-11/td-p/353009 (the latest)

There are multiple elements to take into consideration:

1. Do you want to be a Wi-Fi client (wpa_supplicant) or
2. Do you want to be a Wi-Fi AP (hostapd)

I've looked at the perspective of being a Wi-Fi client (wpa_supplicant), as I'm in the (comfortable and much appreciated) position to have plenty of Stellar Wireless APs around.

Here is how to make WPA3(-Personal) work:

• Assuming you start from Bullseye baseline
• Git clone latest 5.10.Y branch (e.g. git clone --depth=1 --branch rpi-5.10.y https://github.com/raspberrypi/linux)
• (This probably works against later builds, just with different correction-measures)
• Apply Infineon patches against that build (110 at the time of this writing)
• (Cross-)Compile and fix the compilation-errors (note that often just imports are missing, although this is not in the patch-reject; not exactly sure why this is)
• Bring resulting zImage to Pi's /boot as e.g. wifikernel.img and make this your kernel via /boot/config.txt (don't forget to bring the modules to your Pi too)
• Apply/Copy Cypress firmware blobs to /lib/firmware/brcm or /lib/firmware/cypress (note that they apparently to link to /etc/alternatives/
• My Pi4 takes brcm/brcmfmac43455-stdio; you may want to avoid taking chances ;)(e.g. cypress directory uses a different name and links to corresponding /etc/alternatives/)
• Download and compile wpa_supplicant v2.10 with NO cypress patches, just the plain wpa_supplicant
• You need to "sudo apt install libnl-route-3-dev libnl-genl-3-dev libdbus-1-dev libnl-3-dev" to compile wpa_supplicant v2.10 with default configuration

Edit:

• Corrected path /etc/config.txt to /boot/config.txt

[schildbach]

I've got devices ~10 and 20 years old, and running Ubuntu on them enables WPA3 out of the box. So I somehow doubt we need a new chip on the Raspi for WPA3.

[taylorkline]

@BennyE I followed the Arch Wiki instructions for connecting to a mixed WPA2 / WPA3 AP.

Are these instructions incorrect, then?

[jeffsf]

Just the wrong ones for connecting with SAE
https://wiki.archlinux.org/title/wpa_supplicant#Connections_to_pure_WPA3-SAE_access_points

[BennyE]

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command, just replacing the Infineon/Cypress Firmware (without the corresponding Kernel with Infineon/Cypress Patches) will not give you this output. Note that, while the output of iw list lacks the Cipher suite 00-0f-ac:8, it can still use the SAE/SHA-256 Auth-Key-Management (AKM) if the proper wpa_supplicant is used (v2.10 with defconfig -> .config) - the shipped version (v2.9) didn't work for me.

[aannenko]

For me connecting at least to a mixed WPA2/WPA3 network would already be a win!
For now none of the wpa_supplicant.conf configurations let me do a proper headless setup and I always have to connect a monitor and a keyboard my Pi 3B+ with bullseye and then fill /etc/network/interfaces with the following to connect it to my WiFi:

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
    wpa-ssid "NETWORK_NAME"
    wpa-psk "NETWORK_PASSWORD"

To be more specific, the following wpa_supplicant.conf does not connect the Pi to my WiFi:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
country=CZ
update_config=1

network={
    ssid="ssid"
    psk="pass"
    key_mgmt=WPA-PSK-SHA256
    ieee80211w=2
}

The same is true for all variations with or without key_mgmt=WPA-PSK, ieee80211=1, ieee80211=2, proto=RSN, key_mgmt=SAE, sae_password="pass", etc.

Do you guys know if there's a way to construct wpa_supplicant.conf from a manually connected WiFi?

[dilyanpalauzov]

On Raspberry Pi 3 Model B Rev 1.2 (as communicated by /proc/cpuinfo) iw list does not print “Device supports SAE with AUTHENTICATE command”.

[BennyE]

On Raspberry Pi 3 Model B Rev 1.2 (as communicated by /proc/cpuinfo) iw list does not print “Device supports SAE with AUTHENTICATE command”.

It will not display this unless you run a patched kernel + latest Cypress/Infineon firmware (April'22 as of this writing).

[kelnos]

I'm having the same issue as @aannenko -- my Pi3 won't even connect to a WPA2/WPA3 mixed-mode network.

[herrernst]

My RPi 3 connected again to my new WPA2/WPA3 mixed network (OpenWRT) after adding key_mgmt=WPA-PSK-SHA256 and ieee80211w=2 to the WPA config, also mentioned here: #4976 (comment)
Still expected that it would work automatically, didn't have to change anything on my Apple devices.

[masterxq]

Any progress on this?

[blockfeed]

I have a similar configuration as @herrernst, WPA2/WPA3 mixed in OpenWRT. The changes in this comment were the proper combination to get my Pi3 online.

[paulfertser]

No issue on my end:

/etc/wpa_supplicant/wpa_supplicant.conf:

update_config=1

network={
 ssid="ssid"
 key_mgmt=WPA-PSK-SHA256
 psk=psk
 ieee80211w=2
}

WPA-PSK-SHA256 (00-0f-ac:6) isn't supported by WPA3-Personal only mode, see the official WPA3 Specification. So what you got working there is WPA2/RSN with 802.11w MFPR with stronger SHA256-based (but not SAE) AKM.

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command, just replacing the Infineon/Cypress Firmware (without the corresponding Kernel with Infineon/Cypress Patches) will not give you this output. Note that, while the output of iw list lacks the Cipher suite 00-0f-ac:8, it can still use the SAE/SHA-256 Auth-Key-Management (AKM) if the proper wpa_supplicant is used (v2.10 with defconfig -> .config)

I've read the relevant source codes and came to the conclusion that * [ SAE_OFFLOAD ]: SAE offload support in iw phy output is enough, the relevant brcmfmac support was introduced in Linux v5.4-rc1-87-g3b1e0a7bdfee and later a regression for WPA/RSN network fixed in v5.7-rc4-1314-gb2fe11f07773. The Cypress firmware from the Linux firmware git tree is enough, I'm testing with Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2 on AP6255 module.
That said, neither wpa_supplicant v2.10 nor git master support NL80211_ATTR_SAE_PASSWORD attribute for the CMD_CONNECT so this feature isn't available with any wpa_supplicant version.
However, iwd knows how to do that since version 1.13, and I confirm I'm able to use my WPA3-PSK-only AP with this combination (almost-vanilla Linux (just with few unrelated Debian patches, nothing from broadcom), firmware from Linux firmware tree, vanilla iwd), despite 00-0f-ac:8 AKM not listed in the supported ciphers.

[paulfertser]

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command

@BennyE , I see this corresponds to NL80211_FEATURE_SAE wiphy feature, and only qtnfmac upstream driver currently advertises it. Do you know if the corresponding brcmfmac patch was ever submitted upstream? Can you share a patchwork link to it please? I think I can probably imagine how wpa_supplicant can work with that.
In the mean time it seems like using iwd without any additional kernel patches or tricks is a sensible solution for those needing SAE support.