You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wi-Fi networks using only the WPA3 security protocol are showing the 🚫 symbol next to them, and cannot be joined.
The Qualcomm 845 does seem to support WPA3 at a hardware level. (Source: XDA Developers)
Discord user nelsonjchen said the missing Security Flag might be "NM_802_11_AP_SEC_KEY_MGMT_SAE". (Link to post)
See the network "DingoAteYourBaby" in the attached screenshot, which is only using WPA3. The IOT network current connected, has the exact same settings, on the same Access Point, except it is using WPA2.
Tested with two different Wi-Fi networks using only WPA3. It only saves the password, but never connects. Going to guess there's something more than these two lines.
Is there a log file I can provide to help with figuring it out?
I can replicate this on my comma three, and looking at the system logs doesn't give much information. I think we might just have to update the network manager package, which is already on the latest release available in apt for Ubuntu 20.04/agnos...
EDIT: If anyone wants to try and solve this I expect you'll need to temporarily add the jammy (22.04) package list to apt sources and upgrading network manager (remount / as rw and ro again after, and be warned upgrading any package might break your agnos! just try upgrading network manager alone)
The WPA3 network appears in the list grayed out with a "forbidden" icon to the left of the right signal icon. I think I need to patch this in commaai/openpilot#27824.
Patched wifi_manager.cc to be able to connect to my WPA3 SSID but it doesn't work:
selfdrive/ui/qt/network/wifi_manager.cc: DBus call error: "Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken."
Hey guys, bumping this since Wi-Fi 7/MLO becomes more prevalent and WPA3 is being enabled by default on some routers. I tried the recommended implementations on the newest AGNOS, but still it does not connect (https://github.com/MarcoTheDingo/openpilot/tree/wpa3).
Root cause found and fixed in the kernel; WPA3-only networks now connect on a comma four (AGNOS 19.8) with a 4-file qcacld-3.0 change. Details and on-device logs below.
Root cause
drivers/staging/qcacld-3.0/Kbuild only sets CONFIG_WLAN_FEATURE_SAE := y inside ifeq ($(KERNEL_BUILD), 0), the Android external-module path (MODNAME=wlan). AGNOS builds qcacld in-tree (CONFIG_QCA_CLD_WLAN=y, MODNAME empty → KERNEL_BUILD=1), and neither the qcacld Kconfig nor tici_defconfig has an SAE symbol. So -DWLAN_FEATURE_SAE has never been defined in any AGNOS kernel since the 2020 import (commaai/agnos-kernel-sdm845@2c6aed22f9ff).
As a result, the driver never sets NL80211_FEATURE_SAE, and wpa_supplicant drops SAE before it sends CONNECT. This explains the missing csr_send_join_req_msg in the earlier dmesg and NM's ssid-not-found. It is not a NetworkManager / Ubuntu / firmware issue.
The shipped 19.8 boot.img (335c1757…) contains none of the SAE-only log strings, and its .external_auth cfg80211 op is NULL.
Before (stock AGNOS 19.8, comma four, WPA3-only AP: SAE, PMF required, no H2E)
$ wpa_cli -i wlan0 get_capability auth_alg
OPEN SHARED LEAP
NetworkManager: Config: added 'key_mgmt' value 'SAE FT-SAE'
wpa_supplicant: WPA: AP key_mgmt 0x400 network profile key_mgmt 0xc00; available key_mgmt 0x0
wpa_supplicant: WPA: Failed to select authenticated key management type
NetworkManager: Activation: (wifi) association took too long, failing activation
$ nmcli dev wifi connect <ssid> password <pw>
Error: Connection activation failed: The Wi-Fi network could not be found.
Add a WLAN_FEATURE_SAE Kconfig symbol (like WLAN_FEATURE_11W) and set CONFIG_WLAN_FEATURE_SAE=y in tici_defconfig.
Move case NL80211_AUTHTYPE_SAE in wlan_hdd_cfg80211_set_auth_type() out of the WLAN_FEATURE_FILS_SK guard. FILS is off in-tree, so enabling SAE alone still fails with -EINVAL. This matches the newer 5.1.1.75T driver in newer version of wlan driver agnos-kernel-sdm845#98.
Port the "SAE with open authentication" branch in hdd_set_csr_auth_type() from the newer version of wlan driver agnos-kernel-sdm845#98 driver. Without it, SAE AKM + NL80211_AUTHTYPE_OPEN_SYSTEM (sent for PMKSA-caching reconnects, and by NM profiles with auth-alg=open) is mapped to eCSR_AUTH_TYPE_RSN.
Build: agnos19.8 branch, kernel eccd146, comma's GCC 8.2.1 toolchain. A control build without the patch matches the shipped image except for build identity and module-signing key. With the patch, only drivers/staging/qcacld-3.0 (plus init/version.o and kernel/configs.o) is rebuilt. The added strings are all SAE-related.
After (same device, 19.8 + patched boot.img)
$ wpa_cli -i wlan0 get_capability auth_alg
OPEN SHARED LEAP SAE
$ nmcli dev wifi connect <ssid> password <pw>
Device 'wlan0' successfully activated
nl80211: BSS Event 127 (NL80211_CMD_EXTERNAL_AUTH) received for wlan0
SAE: Selecting supported ECC group 19
wlan0: nl80211: External auth status: 0
wlan0: WPA: Key negotiation completed with <bssid> [PTK=CCMP GTK=CCMP]
# DHCP ok, ping ok; BIP (AES-128-CMAC) negotiated
$ wpa_cli -i wlan0 reassociate # PMKSA caching path (fix 3)
wlan0: SAE: Use WPA_AUTH_ALG_OPEN for PMKSA caching attempt
wlan0: CTRL-EVENT-CONNECTED
The stock WLAN firmware (WLAN.HL.2.0.c10-00459, 2019) handles external-auth SAE and PMF fine.
The driver skips firmware roam offload for SAE connections (Roaming not supported for SAE connection, by design in this driver). SAE links reconnect instead of roaming.
Remaining / notes
openpilot UI:get_security_type() still marks SAE-only APs UNSUPPORTED and always creates key-mgmt=wpa-psk profiles.
Ubuntu's wpa_supplicant 2.10 doesn't report sae in D-Bus KeyMgmt for this driver, because the driver advertises no AKM suites (fixed upstream in hostap 2.12, d82c9e61). So NM won't add SAE to wpa-psk profiles on its own.
The UI needs to create key-mgmt=sae profiles (without auth-alg) for SAE-only APs, gated on GET_CAPABILITY auth_alg containing SAE. I have a patch for that, tested on the same device: a WPA3-only AP shows with a lock in the mici UI, and connecting creates a sae profile (key_mgmt SAE FT-SAE, ieee80211w 2, no auth_alg). Saved-profile reconnect works. A wrong password ends in need-auth → failed (no-secrets) after about 26 s, and the UI handles it. Transition APs still use wpa-psk. I'll open that PR after aligning with the NM-removal work (Remove NetworkManager + DBus rom WiFi stack openpilot#37752 / wifi: replace NetworkManager with wpa_supplicant openpilot#38968), since the wpa_supplicant-direct path needs the same change.
WPA2/WPA3 transition networks keep using WPA2-PSK.
Not supported: the driver has no RSNXE/SAE-H2E code, so H2E-only APs (sae_pwe=1, e.g. 6 GHz-style configs) will likely still fail. Hunting-and-pecking works.
Not tested: comma 3X. It uses the same kernel and firmware.
userspace: rebuild wpasupplicant for SAE-H2E #629: rebuilds Ubuntu's wpa_supplicant 2.10 with sae_pwe=2 as the default and the SAE fixes from hostap 2.11/2.12 (advisories 2024-2, 2026-2, 2026-3). NetworkManager behaves as before: transition networks stay WPA2-PSK and the hotspot is unchanged.
Tested on a comma four against a Wi-Fi 7 mesh AP in WPA3-only mode that advertises H2E:
H2E connects (status 126), and RSNXE is in the association request (RSN: set own RSNXE instead of clearing own RSNXE).
PMKSA-cached reconnect and wrong-password handling work.
The stock WLAN firmware relays the H2E auth frames without changes.
My AP supports both SAE methods, so an H2E-only AP is not tested on the device yet. It connects on mac80211_hwsim with hostapd sae_pwe=1.
The first attempt ended in EDL (9008) about 1.4 s after the reset, before ABL picked a slot (boot_a retry count unchanged). A cold boot from port 2 with the PC unplugged booted LD normally.
Problem: reconnecting after a PMF disconnect (filed as commaai/vamOS#131).
On the Deco (Wi-Fi 7, MLO always on), after vamOS disconnects a PMF connection, an immediate reconnect fails for about 40 s to 2 min.
The AP answers with association comeback, the association times out, and auth frames from that MAC then get no answer for a while.
This happened with SAE and with WPA2-PSK + PMF. WPA2-PSK without PMF reconnects in about 1 s.
With a different MAC address the reconnect works in 3 s. So the AP still thinks the old PMF association is alive.
On the same device, AGNOS (qcacld) reconnects to the same SSID in 0-1 s (3/3). It looks like the Deco does not accept the deauth that vamOS sends when it disconnects a PMF link. I have no over-the-air capture to show why.
An iPhone hotspot (no MLO) mostly reconnected right away.
openpilot side:
WPA3-only networks still need a key-mgmt=sae profile.
The UI patch I have checks wpa_supplicant's control socket, which vamOS doesn't create. Since wifi: replace NetworkManager with wpa_supplicant openpilot#38968 replaces NetworkManager, SAE probably belongs there: key_mgmt SAE, ieee80211w, sae_password, global sae_pwe=2.
Side note on recovery: official qdl.js setactiveslot changes only the slot attributes and leaves the partition type GUIDs on the other slot. ABL then refused to boot ('press any key to shutdown') until I restored the GPT. andiradulescu/qdl.js swaps the GUIDs.
Correction to my comment above: I wrote that the mfp feature bit (samcday/pocketfed#27) was not needed on this firmware. That was wrong.
Without the bit, data frames work, but ath10k never marks PMF peers to the firmware. The firmware then sends the protected Deauth with PN 0, the AP drops it, and that causes the reconnect problem in commaai/vamOS#131.
With the bit set, 6 of 7 reconnects took 1-5 s instead of 21-25 s. Captures and details are in commaai/vamOS#131, and the proposed fix is commaai/vamOS#133.
Follow-up for the record (no action needed, since AGNOS is in maintenance mode).
I ran the same measurements on AGNOS 19.8 with the WPA3 kernel and wpa_supplicant from my fork, on the same comma four and AP (5 GHz ch 48, iperf3 30 s each way, profiles created by the openpilot UI):
AGNOS 19.8 + WPA3
vamOS LD 7.2 (stock)
WPA3-only (SAE, PMF required), Mbit/s up / down
259 / 228, 270 / 227
32 / 22, 23 / 22
WPA2/WPA3 mixed
271 / 217 (WPA2-PSK + PMF)
23 / 23 (SAE + PMF)
WPA2-only
268 / 266, 270 / 262
283 / 265, 280 / 272
Reconnect, same MAC
0.8-1.4 s
24 s (status 30)
Connect right after a failed attempt
1.5 s (3/3, wrong SAE password first)
~20 s firmware Auth hold
So the slow PMF links and the reconnect delays only happen on vamOS. qcacld sets the peer PMF flag and cleans up after a failed attempt; ath10k does not. The vamOS side is tracked in commaai/vamOS#131 and commaai/vamOS#133.
The run log, the iperf3 per-second summary and the idle ping results are attached. SSIDs and AP addresses are removed.
Note: I worked through this together with Claude (AI). English is hard for me, so the English was written with AI help. I ran the device tests myself on my comma four, and the results above come from those runs.
Activity
nelsonjchen commentedon Sep 12, 2022
https://github.com/commaai/openpilot/blob/f6398ea7864779f621f84df65ded7ee083e72c09/selfdrive/ui/qt/offroad/wifiManager.cc#L147-L149
Probably just needs an extra flag added here.
I would also say this issue probably only applies to networks with WPA3 only.
adeebshihadeh commentedon Sep 12, 2022
Great, want to open a PR and test it?
MarcoTheDingo commentedon Sep 12, 2022
I am by no means a developer, but I did fork and add the flag in both networkmanager.h & wifiManager.cc.
https://github.com/TheOfficialJosh/openpilot/tree/wifi-wpa3
It sees the network and allows me to type in the password, but it does not actually connect.
Accidentally closed this
MarcoTheDingo commentedon Sep 12, 2022
Tested with two different Wi-Fi networks using only WPA3. It only saves the password, but never connects. Going to guess there's something more than these two lines.
Is there a log file I can provide to help with figuring it out?
incognitojam commentedon Sep 13, 2022
I can replicate this on my comma three, and looking at the system logs doesn't give much information. I think we might just have to update the network manager package, which is already on the latest release available in apt for Ubuntu 20.04/agnos...
EDIT: If anyone wants to try and solve this I expect you'll need to temporarily add the
jammy(22.04) package list to apt sources and upgrading network manager (remount/as rw and ro again after, and be warned upgrading any package might break your agnos! just try upgrading network manager alone)adeebshihadeh commentedon Sep 13, 2022
We build ModemManager from source, might have to do the same for NetworkManager.
[-]Wi-Fi networks with WPA3 are not supported[/-][+][$100 bounty] Wi-Fi networks with WPA3 are not supported[/+][-][$100 bounty] Wi-Fi networks with WPA3 are not supported[/-][+]Wi-Fi networks with WPA3 are not supported[/+]adeebshihadeh commentedon Jul 26, 2024
@andiradulescu you know if 24.04 fixes this for free?
andiradulescu commentedon Jul 26, 2024
As it is, I kind of doubt it. I need to test - switching my router to WPA3 only - let's see what happens when I try to connect from 24.04.
andiradulescu commentedon Jul 26, 2024
The WPA3 network appears in the list grayed out with a "forbidden" icon to the left of the right signal icon. I think I need to patch this in commaai/openpilot#27824.
andiradulescu commentedon Jul 27, 2024
Patched wifi_manager.cc to be able to connect to my WPA3 SSID but it doesn't work:
also tried with nmcli 1.46.0 in Ubuntu 24.04:
compared to a connecting to a WPA2 wifi afterwards
So, it still doesn't work also in Ubuntu 24.04 with Network Manager 1.46.0
MarcoTheDingo commentedon Feb 27, 2025
Hey guys, bumping this since Wi-Fi 7/MLO becomes more prevalent and WPA3 is being enabled by default on some routers. I tried the recommended implementations on the newest AGNOS, but still it does not connect (https://github.com/MarcoTheDingo/openpilot/tree/wpa3).
andiradulescu commentedon Feb 27, 2025
From what I remember it will work only with kernel driver support. Or when we switch to mainline.
shunnag commentedon Sep 24, 2026
Root cause found and fixed in the kernel; WPA3-only networks now connect on a comma four (AGNOS 19.8) with a 4-file qcacld-3.0 change. Details and on-device logs below.
Root cause
drivers/staging/qcacld-3.0/Kbuildonly setsCONFIG_WLAN_FEATURE_SAE := yinsideifeq ($(KERNEL_BUILD), 0), the Android external-module path (MODNAME=wlan). AGNOS builds qcacld in-tree (CONFIG_QCA_CLD_WLAN=y,MODNAMEempty →KERNEL_BUILD=1), and neither the qcacld Kconfig nortici_defconfighas an SAE symbol. So-DWLAN_FEATURE_SAEhas never been defined in any AGNOS kernel since the 2020 import (commaai/agnos-kernel-sdm845@2c6aed22f9ff).As a result, the driver never sets
NL80211_FEATURE_SAE, and wpa_supplicant drops SAE before it sends CONNECT. This explains the missingcsr_send_join_req_msgin the earlier dmesg and NM'sssid-not-found. It is not a NetworkManager / Ubuntu / firmware issue.The shipped 19.8
boot.img(335c1757…) contains none of the SAE-only log strings, and its.external_authcfg80211 op is NULL.Before (stock AGNOS 19.8, comma four, WPA3-only AP: SAE, PMF required, no H2E)
Fix
Kernel PR: commaai/agnos-kernel-sdm845#142. It changes 4 files (+11/−2):
WLAN_FEATURE_SAEKconfig symbol (likeWLAN_FEATURE_11W) and setCONFIG_WLAN_FEATURE_SAE=yintici_defconfig.case NL80211_AUTHTYPE_SAEinwlan_hdd_cfg80211_set_auth_type()out of theWLAN_FEATURE_FILS_SKguard. FILS is off in-tree, so enabling SAE alone still fails with-EINVAL. This matches the newer 5.1.1.75T driver in newer version of wlan driver agnos-kernel-sdm845#98.hdd_set_csr_auth_type()from the newer version of wlan driver agnos-kernel-sdm845#98 driver. Without it, SAE AKM +NL80211_AUTHTYPE_OPEN_SYSTEM(sent for PMKSA-caching reconnects, and by NM profiles withauth-alg=open) is mapped toeCSR_AUTH_TYPE_RSN.Build: agnos19.8 branch, kernel eccd146, comma's GCC 8.2.1 toolchain. A control build without the patch matches the shipped image except for build identity and module-signing key. With the patch, only
drivers/staging/qcacld-3.0(plusinit/version.oandkernel/configs.o) is rebuilt. The added strings are all SAE-related.After (same device, 19.8 + patched boot.img)
The stock WLAN firmware (
WLAN.HL.2.0.c10-00459, 2019) handles external-auth SAE and PMF fine.The driver skips firmware roam offload for SAE connections (
Roaming not supported for SAE connection, by design in this driver). SAE links reconnect instead of roaming.Remaining / notes
get_security_type()still marks SAE-only APsUNSUPPORTEDand always createskey-mgmt=wpa-pskprofiles.saein D-BusKeyMgmtfor this driver, because the driver advertises no AKM suites (fixed upstream in hostap 2.12, d82c9e61). So NM won't add SAE towpa-pskprofiles on its own.key-mgmt=saeprofiles (withoutauth-alg) for SAE-only APs, gated onGET_CAPABILITY auth_algcontainingSAE. I have a patch for that, tested on the same device: a WPA3-only AP shows with a lock in the mici UI, and connecting creates asaeprofile (key_mgmt SAE FT-SAE,ieee80211w 2, noauth_alg). Saved-profile reconnect works. A wrong password ends inneed-auth→failed (no-secrets)after about 26 s, and the UI handles it. Transition APs still usewpa-psk. I'll open that PR after aligning with the NM-removal work (Remove NetworkManager + DBus rom WiFi stack openpilot#37752 / wifi: replace NetworkManager with wpa_supplicant openpilot#38968), since the wpa_supplicant-direct path needs the same change.Full before/after logs (redacted): https://gist.github.com/shunnag/90458a4e96a36e6260145a9ab1226edd
shunnag commentedon Sep 25, 2026
Follow-up for SAE hash-to-element (H2E), which my earlier comment listed as unsupported:
sae_pwe=2as the default and the SAE fixes from hostap 2.11/2.12 (advisories 2024-2, 2026-2, 2026-3). NetworkManager behaves as before: transition networks stay WPA2-PSK and the hotspot is unchanged.Tested on a comma four against a Wi-Fi 7 mesh AP in WPA3-only mode that advertises H2E:
RSN: set own RSNXEinstead ofclearing own RSNXE).My AP supports both SAE methods, so an H2E-only AP is not tested on the device yet. It connects on mac80211_hwsim with hostapd
sae_pwe=1.adeebshihadeh commentedon Sep 26, 2026
Thanks, this is good to know. Can you port your changes over to our new OS, vamOS? AGNOS is currently in maintenance mode.
shunnag commentedon Sep 26, 2026
Thanks for taking a look! I'll see if I can port my changes to vamOS.
shunnag commentedon Sep 26, 2026
I tried vamOS on my comma four. WPA3-Personal works there without porting anything, but I found one reconnect problem with PMF.
Setup:
vamos.json442f27c3), installed into the inactive slot the way dorapilot does it.Nothing from the AGNOS work needs porting. commaai/agnos-kernel-sdm845#142, commaai/agnos-kernel-sdm845#143 and #629 are qcacld- and Ubuntu-2.10-specific. With mac80211, wpa_supplicant does SAE itself, and NetworkManager sets
SaePwe=2.What works on vamOS:
sae_h2e=1, RSNXEf4 01 20). DHCP and ping work.wpa-pskprofile, because NM adds SAE. Tested on the Deco and on an iPhone hotspot.mfpfeature bit (see sargo: declare WCN3990 management-frame protection support samcday/pocketfed#27): not needed on this firmware. PMF links pass data with the stockfirmware-5.bin. Setting the bit changed nothing I could see.Problem: reconnecting after a PMF disconnect (filed as commaai/vamOS#131).
openpilot side:
key-mgmt=saeprofile.key_mgmt SAE,ieee80211w,sae_password, globalsae_pwe=2.Side note on recovery: official qdl.js
setactiveslotchanges only the slot attributes and leaves the partition type GUIDs on the other slot. ABL then refused to boot ('press any key to shutdown') until I restored the GPT. andiradulescu/qdl.js swaps the GUIDs.I can share redacted logs if they help.
shunnag commentedon Sep 26, 2026
Correction to my comment above: I wrote that the
mfpfeature bit (samcday/pocketfed#27) was not needed on this firmware. That was wrong.Without the bit, data frames work, but ath10k never marks PMF peers to the firmware. The firmware then sends the protected Deauth with PN 0, the AP drops it, and that causes the reconnect problem in commaai/vamOS#131.
With the bit set, 6 of 7 reconnects took 1-5 s instead of 21-25 s. Captures and details are in commaai/vamOS#131, and the proposed fix is commaai/vamOS#133.
shunnag commentedon Oct 1, 2026
Follow-up for the record (no action needed, since AGNOS is in maintenance mode).
I ran the same measurements on AGNOS 19.8 with the WPA3 kernel and wpa_supplicant from my fork, on the same comma four and AP (5 GHz ch 48, iperf3 30 s each way, profiles created by the openpilot UI):
So the slow PMF links and the reconnect delays only happen on vamOS. qcacld sets the peer PMF flag and cleans up after a failed attempt; ath10k does not. The vamOS side is tracked in commaai/vamOS#131 and commaai/vamOS#133.
The run log, the iperf3 per-second summary and the idle ping results are attached. SSIDs and AP addresses are removed.
Note: I worked through this together with Claude (AI). English is hard for me, so the English was written with AI help. I ran the device tests myself on my comma four, and the results above come from those runs.
agnos_wpa3_measurements.txt