## Bug summary
ZimaOS v1.6.2 cannot connect to WPA3-Personal Wi‑Fi networks because the bundled `wpa_supplicant` was built without SAE support.
This also prevents connecting to all 6 GHz Wi‑Fi networks, since 6 GHz requires WPA3-Personal/SAE (or Enhanced Open), rather than WPA2-Personal.
The failure is local and occurs before authentication or association with the access point.
## Environment
- Device: ZimaCube
- OS: ZimaOS v1.6.2
- Build date: 2026-07-09
- Architecture: amd64
- Wi‑Fi adapter: MediaTek MT7925 802.11be PCIe (Filogic 360)
- Kernel driver: `mt7925e`
- Network manager: NetworkManager with wpa_supplicant backend
- Router security: WPA3-Personal, AES/CCMP
- Router 6 GHz configuration:
- SSID: `test6G`
- Primary channel: 5
- Frequency: 5975 MHz
- Width: 160 MHz
- PSC enabled
- Wi‑Fi 7 and MLO disabled for troubleshooting
## Expected behavior
ZimaOS should connect to a standard WPA3-Personal 6 GHz SSID using SAE with PMF required.
## Actual behavior
The 6 GHz network is detected correctly, but connection activation fails with:
```text
Error: Connection activation failed: 802.1X supplicant failed
NetworkManager passes the expected WPA3 parameters to wpa_supplicant:
Config added key_mgmt value SAE FT-SAE
Config added ieee80211w value 2
However, the bundled wpa_supplicant rejects both SAE algorithms:
Line 0: invalid key_mgmt 'SAE'
Line 0: invalid key_mgmt 'FT-SAE'
Line 0: no key_mgmt values configured.
NetworkManager then fails the connection:
failure to add network: invalid message format
device (wlan0): state change: config -> failed (reason 'supplicant-failed')
Activation failed for connection test6G
Evidence that radio, driver, AP, and regulatory domain work
The MT7925E adapter successfully detects the 6 GHz access point:
BSS 60:cf:84:3a:90:69(on wlan0)
freq: 5975.0
signal: -58.00 dBm
SSID: test6G
The access point advertises valid 6 GHz operation information:
6 GHz Operation Information:
Primary Channel: 5
Channel Width: 80+80 or 160 MHz
The adapter reports 6 GHz support:
GENERAL.DRIVER: mt7925e
WIFI-PROPERTIES.6GHZ: yes
The active regulatory domain is DE, which allows the AP frequency:
country DE: DFS-ETSI
(5945 - 6425 @ 320), (N/A, 23), (N/A), NO-OUTDOOR
The SSID is on 5975 MHz, therefore it is within the allowed 5945–6425 MHz range.
The same adapter and NetworkManager installation connect successfully to a separate WPA2-Personal 5 GHz SSID. Therefore the issue is specifically the lack of WPA3-SAE support in the shipped supplicant build.
Reproduction steps
-
Use ZimaOS v1.6.2 on ZimaCube with a Wi‑Fi adapter supported by mt7925e.
-
Create or use a WPA3-Personal-only Wi‑Fi network.
-
For a 6 GHz test, configure a legal PSC channel, for example channel 5 / 5975 MHz.
-
Scan successfully:
sudo nmcli device wifi rescan ifname wlan0
nmcli device wifi list ifname wlan0
-
Create a WPA3-SAE profile:
sudo nmcli connection add \
type wifi \
ifname wlan0 \
con-name 'test6G' \
ssid 'test6G'
sudo nmcli connection modify 'test6G' \
802-11-wireless.mode infrastructure \
802-11-wireless.band a \
802-11-wireless-security.key-mgmt sae \
802-11-wireless-security.pmf 3 \
ipv4.method auto \
ipv6.method auto
-
Add a valid password and activate the profile:
sudo nmcli connection modify 'test6G' \
802-11-wireless-security.psk 'REDACTED'
sudo nmcli connection up 'test6G' ifname wlan0
-
Observe the invalid key_mgmt SAE and invalid key_mgmt FT-SAE errors in the journal.
Requested fix
Please enable WPA3 support in the Buildroot wpa_supplicant configuration used for ZimaOS.
At minimum, the wpa_supplicant build must include:
CONFIG_IEEE80211W=y
CONFIG_SAE=y
Please also enable FT-SAE support where appropriate.
Buildroot provides a WPA3 support option for wpa_supplicant, and CONFIG_SAE=y is the required compile-time option for WPA3-Personal/SAE. Without it, NetworkManager cannot activate any WPA3-Personal connection and ZimaOS cannot use 6 GHz Wi‑Fi.
Impact
This affects:
- Any WPA3-Personal-only network
- Every standard secured 6 GHz Wi‑Fi network
- Wi‑Fi 6E and Wi‑Fi 7 client use cases on ZimaOS
- Modern routers configured securely without WPA2 fallback
Additional notes
iwd is not installed in the ZimaOS v1.6.2 image, so there is no alternative wireless backend available as a workaround.
- The issue is not caused by the regulatory domain, channel width, router signal, or MT7925E driver.
- A local workaround is to use a separate WPA2-Personal 5 GHz SSID, but WPA2 cannot be used as a fallback on 6 GHz.
NetworkManager passes the expected WPA3 parameters to wpa_supplicant:
However, the bundled wpa_supplicant rejects both SAE algorithms:
NetworkManager then fails the connection:
Evidence that radio, driver, AP, and regulatory domain work
The MT7925E adapter successfully detects the 6 GHz access point:
The access point advertises valid 6 GHz operation information:
The adapter reports 6 GHz support:
The active regulatory domain is
DE, which allows the AP frequency:The SSID is on 5975 MHz, therefore it is within the allowed 5945–6425 MHz range.
The same adapter and NetworkManager installation connect successfully to a separate WPA2-Personal 5 GHz SSID. Therefore the issue is specifically the lack of WPA3-SAE support in the shipped supplicant build.
Reproduction steps
Use ZimaOS v1.6.2 on ZimaCube with a Wi‑Fi adapter supported by
mt7925e.Create or use a WPA3-Personal-only Wi‑Fi network.
For a 6 GHz test, configure a legal PSC channel, for example channel 5 / 5975 MHz.
Scan successfully:
Create a WPA3-SAE profile:
Add a valid password and activate the profile:
Observe the
invalid key_mgmt SAEandinvalid key_mgmt FT-SAEerrors in the journal.Requested fix
Please enable WPA3 support in the Buildroot wpa_supplicant configuration used for ZimaOS.
At minimum, the wpa_supplicant build must include:
Please also enable FT-SAE support where appropriate.
Buildroot provides a WPA3 support option for wpa_supplicant, and
CONFIG_SAE=yis the required compile-time option for WPA3-Personal/SAE. Without it, NetworkManager cannot activate any WPA3-Personal connection and ZimaOS cannot use 6 GHz Wi‑Fi.Impact
This affects:
Additional notes
iwdis not installed in the ZimaOS v1.6.2 image, so there is no alternative wireless backend available as a workaround.