Pi Zero W 2 wifi won't connect - PMF optional breaks auth, disable to fix

TL;DR: Had to fully disable PMF (ieee80211w '0') to get my Pi Zero W 2 to connect. PMF optional worked fine on Ubiquiti but breaks authentication on OpenWrt. Not sure if this is a bug or different implementation.

I switched from Ubiquiti devices to a GL.iNet Flint 2 running OpenWrt (24.10.3 r28872-daca7c049b) and my Pi Zero W 2 (running Venus OS for solar monitoring) suddenly wouldn't connect to my 2.4GHz WPA2/WPA3 mixed network. It would just sit at "Connecting..." forever and never get a DHCP address. This was the only device having problems. Everything else connected fine.

What I tried that didn't work:

  • Changed from WiFi 6 (HE20) to 802.11n (HT20)
  • Switched from WPA2/WPA3 mixed to WPA2-only
  • Disabled 802.11r/k/v
  • Enabled legacy 802.11b rates

How I found the issue:

Ran logread -f on OpenWrt while connecting and saw:

hostapd: phy0-ap1: STA <MAC> IEEE 802.11: authenticated
hostapd: phy0-ap1: STA <MAC> IEEE 802.11: associated (aid 1)
hostapd: phy0-ap1: AP-STA-POSSIBLE-PSK-MISMATCH <MAC>

The device was showing up in iw dev phy0-ap1 station dump (associated at WiFi layer, -40 dBm signal, 6.0 Mbps) but failing authentication with a PSK mismatch error. Password was definitely correct.

Solution:

Disabled PMF completely:

option ieee80211w '0'

Connected immediately after wifi reload.

The weird part:

PMF was set to optional (ieee80211w '1') which should theoretically allow devices without PMF support to connect. Same Pi Zero W 2 connected fine to Ubiquiti with PMF optional. OpenWrt's optional PMF setting doesn't seem to behave the same way.

Device specs: Pi Zero W 2 has a Broadcom BCM43436 chip (802.11b/g/n only)

If you're seeing similar "connecting forever" issues with older devices on OpenWrt, try disabling PMF on that SSID.

From the pi zero w

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/wireless
iw phy # extract interface modes, interface combinations and channel lists
# ubus call system board
{
	"kernel": "6.6.104",
	"hostname": "<redacted>",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT6000",
	"board_name": "glinet,gl-mt6000",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.3",
		"revision": "r28872-daca7c049b",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.3 r28872-daca7c049b",
		"builddate": "1758316778"
	}
}

Note: You just need to change option ieee80211w '0' from 0 to 1 on the 2.4ghz network to make it so the Pi Zero W 2 won't connect again.

# cat /etc/config/wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option path 'platform/soc/18000000.wifi'
    option band '2g'
    option channel '6'
    option country 'US'
    option cell_density '0'
    option htmode 'HE20'

config wifi-device 'radio1'
    option type 'mac80211'
    option path 'platform/soc/18000000.wifi+1'
    option band '5g'
    option channel '153'
    option htmode 'HE40'
    option country 'US'
    option cell_density '0'

config wifi-iface 'guest_radio0'
    option device 'radio0'
    option network 'vlan6'
    option mode 'ap'
    option ssid '<redacted>'
    option encryption 'sae-mixed'
    option key '<redacted>'
    option ieee80211w '0'
    option isolate '1'
    option ieee80211k '1'
    option ieee80211v '1'
    option ieee80211r '1'
    option ft_over_ds '0'
    option mobility_domain 'a1b2'
    option reassociation_deadline '20000'
    option wnm_sleep_mode '1'

config wifi-iface 'guest_radio1'
    option device 'radio1'
    option network 'vlan6'
    option mode 'ap'
    option ssid '<redacted>'
    option encryption 'sae-mixed'
    option key '<redacted>'
    option ieee80211w '1'
    option isolate '1'
    option disabled '0'
    option ocv '0'
    option ieee80211k '1'
    option ieee80211v '1'
    option ieee80211r '1'
    option ft_over_ds '0'
    option mobility_domain 'a1b2'
    option reassociation_deadline '20000'
    option wnm_sleep_mode '1'

Relevant info from iw phy:

# Interface Modes (both phy0 and phy1 support):
Supported interface modes:
     * IBSS
     * managed
     * AP
     * AP/VLAN
     * monitor
     * mesh point
     * P2P-client
     * P2P-GO

# Interface Combinations (both phy0 and phy1):
valid interface combinations:
     * #{ IBSS } <= 1, #{ AP, mesh point } <= 16, #{ managed } <= 19,
       total <= 19, #channels <= 1, STA/AP BI must match, 
       radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

# phy0 - 2.4GHz Band Channels:
Frequencies:
     * 2412.0 MHz [1] (30.0 dBm)
     * 2417.0 MHz [2] (30.0 dBm)
     * 2422.0 MHz [3] (30.0 dBm)
     * 2427.0 MHz [4] (30.0 dBm)
     * 2432.0 MHz [5] (30.0 dBm)
     * 2437.0 MHz [6] (30.0 dBm)
     * 2442.0 MHz [7] (30.0 dBm)
     * 2447.0 MHz [8] (30.0 dBm)
     * 2452.0 MHz [9] (30.0 dBm)
     * 2457.0 MHz [10] (30.0 dBm)
     * 2462.0 MHz [11] (30.0 dBm)
     * 2467.0 MHz [12] (disabled)
     * 2472.0 MHz [13] (disabled)
     * 2484.0 MHz [14] (disabled)

# phy1 - 5GHz Band Channels:
Frequencies:
     * 5180-5240 MHz [36-48] (23.0 dBm)
     * 5260-5720 MHz [52-144] (24.0 dBm) (radar detection)
     * 5745-5825 MHz [149-165] (30.0 dBm)
     * 5845-5885 MHz [169-177] (27.0 dBm) (no IR)

This looks more like mediatek, please get iw infoes from broadcom’s limited stuff… KVR stuff makes no benefit unless you have a voip phone explicitly supporting & recommending it, or >5yo device needing kick to upper band not migrating on its own.

Sorry for the confusion. Thought you meant SSH into the OpenWrt router. Yeah, that first iw phy output was from the GL-MT6000's MediaTek radios, not the Pi.

I've now SSH'd into the Pi Zero W 2 and gathered this:

# iw phy phy0 info | grep -A 20 "Supported Ciphers"
Supported Ciphers:
    * WEP40 (00-0f-ac:1)
    * WEP104 (00-0f-ac:5)
    * TKIP (00-0f-ac:2)
    * CCMP-128 (00-0f-ac:4)
    * CMAC (00-0f-ac:6)
Available Antennas: TX 0 RX 0
Supported interface modes:
     * IBSS
     * managed
     * AP
     * P2P-client
     * P2P-GO
     * P2P-device
Band 1:
    Capabilities: 0x1020
        HT20
        Static SM Power Save
        RX HT20 SGI
        No RX STBC
# iw phy phy0 info | grep -i "MFP"
(no output)
# iw phy phy0 info | grep "Supported extended features" -A 30
Supported extended features:
    * [ 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
    * [ SAE_OFFLOAD ]: SAE offload support
# iw dev wlan0 station dump
Station <mac> (on wlan0)
    inactive time:  0 ms
    rx bytes:   868277
    rx packets: 6856
    signal:     -36 dBm
    signal avg: -36 [-36] dBm
    tx bitrate: 72.2 MBit/s
    rx bitrate: 72.2 MBit/s
    authorized: yes
    authenticated:  yes
    associated: yes
# uname -a
Linux raspberrypi2 5.10.110 #1 SMP Fri Mar 14 13:49:56 UTC 2025 armv7l GNU/Linux
# dmesg | grep -i brcm
[    7.173969] brcmfmac: F1 signature read @0x18000000=0x1542a9a6
[    7.190435] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43436-sdio for chip BCM43430/2
[    7.457224] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/2 wl0: Mar 31 2022 17:24:51 version 9.88.4.77 (g58bc5cc) FWID 01-3b307371
[   15.818354] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

Full iw phy phy0 info output attached below. Venus OS uses ConnMan for network management, not wpa_supplicant directly.

Full iw phy phy0 info
Wiphy phy0
	wiphy index: 0
	max # scan SSIDs: 10
	max scan IEs length: 2048 bytes
	max # sched scan SSIDs: 16
	max # match sets: 16
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports roaming.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CMAC (00-0f-ac:6)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * P2P-client
		 * P2P-GO
		 * P2P-device
	Band 1:
		Capabilities: 0x1020
			HT20
			Static SM Power Save
			RX HT20 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412.0 MHz [1] (20.0 dBm)
			* 2417.0 MHz [2] (20.0 dBm)
			* 2422.0 MHz [3] (20.0 dBm)
			* 2427.0 MHz [4] (20.0 dBm)
			* 2432.0 MHz [5] (20.0 dBm)
			* 2437.0 MHz [6] (20.0 dBm)
			* 2442.0 MHz [7] (20.0 dBm)
			* 2447.0 MHz [8] (20.0 dBm)
			* 2452.0 MHz [9] (20.0 dBm)
			* 2457.0 MHz [10] (20.0 dBm)
			* 2462.0 MHz [11] (20.0 dBm)
			* 2467.0 MHz [12] (disabled)
			* 2472.0 MHz [13] (disabled)
			* 2484.0 MHz [14] (disabled)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * join_ibss
		 * set_pmksa
		 * del_pmksa
		 * flush_pmksa
		 * remain_on_channel
		 * frame
		 * set_wiphy_netns
		 * set_channel
		 * start_sched_scan
		 * start_p2p_device
		 * connect
		 * disconnect
		 * crit_protocol_start
		 * crit_protocol_stop
		 * update_connect_params
	software interface modes (can always be added):
	valid interface combinations:
		 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
		   total <= 3, #channels <= 2
		 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
		   total <= 4, #channels <= 1
	Device supports scan flush.
	Device supports randomizing MAC-addr in sched scans.
	max # scan plans: 1
	max scan plan interval: 508
	max scan plan iterations: 0
	Supported TX frame types:
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	Supported extended features:
		* [ 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
		* [ SAE_OFFLOAD ]: SAE offload support

The chip supports CMAC cipher (00-0f-ac:6) but there's no MFP_CAPABLE or MFP_OPTIONAL flag in the extended features (explanation here). Currently connected with PMF disabled (ieee80211w '0') on the AP. Remember, the weird part is this actually worked with Optional PMF on Ubiquiti hardware.

you have to ask them

NM detects cryoto mode, if you connect wpa3 once it prevents downgrade, essentially delete and reconnect.

1 Like

Now I'm thinking this actually wasn't related to openwrt.

I ended up trying to swap the pi zero w 2 to a compute module 4 with a newer wifi chip, and it has the same issue. So 802.11w was likely broken in Victron's Venus OS (which uses debian) by a recent update (applied around the time I was swapping to the flint 2).

You can try zero w with openwrt on sd-card. Maybe Venus OS is eagerly waiting for your report :wink: