Venus OS v3.66: Raspberry Pi WiFi connectivity broken with PMF/802.11w enabled

Modifications
, , ,
1

WiFi connections fail on Raspberry Pi devices running Venus OS when the access point has PMF (802.11w / Protected Management Frames) enabled, even in optional mode. Issue confirmed on v3.66 with Compute Module 4. Connections only succeed when PMF is completely disabled on the AP.

Venus OS v3.55 may have been the last version with stable wifi for Raspberry Pi Zero W 2.

Related Issues

Affected Devices

  • Raspberry Pi Zero W 2 (Broadcom BCM43436, 802.11b/g/n)

  • Raspberry Pi Compute Module 4

Both tested on Venus OS v3.66 with identical PMF connection failures.

Symptoms

  • WiFi shows “Connecting…” indefinitely

  • Never obtains DHCP address

  • AP side logs (OpenWrt hostapd) show:

    • Device authenticates successfully

    • Device associates successfully (visible in station dump, good signal)

    • AP-STA-POSSIBLE-PSK-MISMATCH error despite correct password

    • Connection fails during 4-way handshake

What Changed

WiFi connectivity with PMF optional worked on previous Venus OS version (likely v3.55). After upgrading to v3.66, connections fail with PMF enabled on the access point. Testing with Compute Module 4 (different WiFi chip) on v3.66 showed identical failures, confirming this is a Venus OS software regression.

Workaround

Disable PMF on the access point:

  • OpenWrt: option ieee80211w '0' in /etc/config/wireless

Connection works immediately after disabling PMF.

Additional Information

Full diagnostic output including iw phy info and AP-side logs available in OpenWrt forum post: Pi Zero W 2 wifi won't connect - PMF optional breaks auth, disable to fix - Installing and Using OpenWrt - OpenWrt Forum

Note: The Venus OS upgrade to v3.66 happened at the same time as I was changing access points, which initially caused confusion about whether this was a router compatibility issue or a Venus OS regression. Testing with the Compute Module 4 on v3.66 confirmed it’s a Venus OS issue.

2

Hi,

Venus OS 3.67 (acting as wifi client) use ‘connman’ to manage wifi interface.

To my knowledge ‘connman’ use ‘wpa_supplicant’ library to create/run wifi interface.

By default ‘wpa_supplicant’ support for “Protected Management Frames” (PMF) is disabled.

You need to enable client PMF support by option pmf=1 | ieee80211w=1 (optional) or pmf=2 | ieee80211w=2 (required) at wpa_supplicant.conf file.

As Venus OS use ‘connman’ without wpa_supplicant.conf file support, it is not possible to active “Protected Management Frames” at wifi client side.

AP (MFP/PMF disabled) works.

AP (MFP/PMF optional) works (Venus OS as client will not use MFP/PMF even if underlaying Venus OS wifi client hardware support it)

AP (MFP/PMF required) failed (Venus OS as client can not configured to make use of MFP/PMF).

edit:

Venus OS 3.67 based on openembedded-core (branch honister)

openembedded-core ‘wpa_supplicant’ configured WITHOUT MFP/PMF support.

3

@and Thanks for the info on how connman/wpa_supplicant handles PMF under the hood.

A couple of things I’m trying to understand though. The original issue is specifically about v3.66 failing with PMF set to *optional* on the AP, not required. If wpa_supplicant has PMF disabled by default (as you describe), then connecting to an AP with PMF optional should still work, since the AP shouldn’t force PMF on a client that doesn’t support it.

Also, you mention 3.67 specifically. Did something change between 3.66 and 3.67 related to this? I don’t see anything in the changelogs about connman or wpa_supplicant changes. Are you saying the behavior is the same in 3.67, or that something was addressed? Would be helpful to clarify what you’re suggesting as a path forward here.

4

Just saw your edit. That’s helpful, thanks for digging into the defconfig. So wpa_supplicant is compiled without CONFIG_IEEE80211W entirely on the honister branch. That would explain why PMF required fails for sure.