Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Wi-Fi Protected Access 3 (WPA3) support #4718

Open
ghost opened this issue Nov 19, 2021 · 102 comments
Open

Wi-Fi Protected Access 3 (WPA3) support #4718

ghost opened this issue Nov 19, 2021 · 102 comments
Labels
Close within 30 days Issue will be closed within 30 days unless requested to stay open Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team

Comments

@ghost
Copy link

ghost commented Nov 19, 2021

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
Copy link
Contributor

pelwell commented Nov 22, 2021

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

@pelwell pelwell added Close within 30 days Issue will be closed within 30 days unless requested to stay open Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team labels Nov 23, 2021
@kroon040
Copy link

Is wpa3 possible with debian bullseye with Pi zero w2?

@pelwell
Copy link
Contributor

pelwell commented Nov 26, 2021

No Raspberry Pi currently supports WPA3.

@kroon040
Copy link

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

@JamesH65
Copy link
Contributor

"No Raspberry Pi supports WPA3"

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

@jfargen
Copy link

jfargen commented Nov 29, 2021

@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
Copy link
Contributor

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

@JsBergbau
Copy link

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
Copy link

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
Copy link

jetflux commented Feb 9, 2022

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
Copy link

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
Copy link

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

@taylorkline
Copy link

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
Copy link
Contributor

jeffsf commented Jun 13, 2022

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
Copy link

BennyE commented Jun 14, 2022 •
edited
Loading

@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
}

grafik

@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
Copy link

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
Copy link

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

Are these instructions incorrect, then?

@jeffsf
Copy link
Contributor

jeffsf commented Jun 14, 2022

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

@BennyE
Copy link

BennyE commented Jun 15, 2022

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
Copy link

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
Copy link

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
Copy link

BennyE commented Jul 10, 2022 •
edited
Loading

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
Copy link
Contributor

kelnos commented Aug 2, 2022

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

@herrernst
Copy link

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
Copy link

Any progress on this?

@blockfeed
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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.

@paulfertser
Copy link
Contributor

paulfertser commented Jan 31, 2024 via email

@jebanon
Copy link

jebanon commented Jan 31, 2024

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
Copy link

jebanon commented Feb 4, 2024

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: RPi-Distro/firmware-nonfree@ad23f33)
  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
Copy link

kwinz commented Feb 6, 2024 •
edited
Loading

@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
Copy link

jebanon commented Feb 6, 2024 •
edited
Loading

@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 old chip firmware (and that raspberry pi is "shipping" old firmware that is probably missing newer security fixes, features, etc).

@pelwell
Copy link
Contributor

pelwell commented Feb 7, 2024 •
edited
Loading

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
Copy link

jebanon commented Feb 7, 2024

@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
Copy link
Contributor

pelwell commented Feb 7, 2024

214 patches is not minimal.

@pelwell
Copy link
Contributor

pelwell commented Feb 12, 2024

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
Copy link

0d0a commented Feb 13, 2024 via email

@pelwell
Copy link
Contributor

pelwell commented Feb 13, 2024

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
Copy link

0d0a commented Feb 13, 2024 via email

@pelwell
Copy link
Contributor

pelwell commented Feb 13, 2024

And:

On which software did this last work?

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

@0d0a
Copy link

0d0a commented Feb 13, 2024 via email

@jebanon
Copy link

jebanon commented Feb 14, 2024

@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
Copy link
Contributor

paulfertser commented Feb 14, 2024 via email

@jebanon
Copy link

jebanon commented Feb 14, 2024

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.

@fhunleth fhunleth mentioned this issue Feb 19, 2024
Closed
@BroJac5246
Copy link

+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
Copy link
Contributor

gearhead commented May 14, 2024 •
edited
Loading

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.

@billyvg
Copy link

billyvg commented Aug 20, 2024

raspberry pi 5 + bookworm + WPA3 + patched firmware:

image

key mgmt = sae

wifi won't connect on boot, won't connect when using saved password, won't connect when specifying a password using nmcli e.g. nmcli dev wifi connect ssid password mypassword

BUT it does connect when using --ask to prompt for a password: nmcli --ask dev wifi connect ssid

Seems like some wires are getting crossed with the passwords.

@pelwell
Copy link
Contributor

pelwell commented Aug 22, 2024

What do you mean by ”patched firmware”?

@MichaIng
Copy link

Probably the one you linked here: #5945
But maybe it is in your firmware-brcm80211 already?

@gearhead
Copy link
Contributor

If you've done an apt update to a bookworm install on your Pi, you should have the latest firmware. You can confirm by this:

# dmesg | grep brcmfmac
[    1.989107] brcmfmac: F1 signature read @0x18000000=0x15264345
[    1.995329] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    2.014048] usbcore: registered new interface driver brcmfmac
[    2.281429] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[    2.281695] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b

Note the version 7.45.265 with a date of Aug 29 2023. It will connect to SAE3 with wpa_supplicant. I was unable to use wpa_cli but was able to use nmcli to connect. It does not yet work with connman afaict. It also is not yet compatible with iwd.

@MattBlack85 MattBlack85 mentioned this issue Aug 23, 2024
Closed
@jebanon
Copy link

jebanon commented Aug 23, 2024

It also is not yet compatible with iwd.

Does anybody know if compatibility of the latest firmware (.265) with iwd will ever be possible? Is anybody working on the changes to iwd that would enable it to support the SAE changes? Is there any indication that iwd would someday replace wpa_supplicant as the default on Raspbian or other distros (I kinda hope so, but only if it supports WPA3)?

@gearhead
Copy link
Contributor

The iwd team posted a patch yesterday. I tested it today and it gets further but still does not grab an IP. Based on this development, I think they are 'working on it'.

@agners agners mentioned this issue Oct 12, 2024
Closed
@poeggi
Copy link

poeggi commented Oct 14, 2024

Is wpa3 possible with debian bullseye with Pi zero w2?

Just to clarify: No, Its not. Just tested myself.

@gearhead
Copy link
Contributor

gearhead commented Oct 14, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Close within 30 days Issue will be closed within 30 days unless requested to stay open Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests