[Pi Zero 2 W] Wi-Fi disassociates and reconnects exactly every 60 seconds

Start by reproducing the 60-second cycle with the Raspberry Pi Zero 2 W, OpenWrt hostapd logs, and the listed NetworkManager, wpa_supplicant, and brcmfmac settings. Compare the behavior across the latest firmware and the documented workarounds to identify whether the reset originates in the host software or firmware; done means explaining the responsible layer and preventing the recurring disassociation.

Description

I am experiencing a very specific and consistent Wi-Fi issue with the Raspberry Pi Zero 2 W. The device drops the Wi-Fi connection and immediately reconnects exactly every 60-61 seconds.

Because the reconnection takes only about 1-2 seconds, TCP connections (like SSH) usually survive and just "freeze" for a moment. However, analyzing the Access Point logs reveals a continuous, endless loop of disassociated -> authenticated -> associated -> connected occurring every minute.

Prior to updating firmware-brcm80211 to the latest 2025 build, the AP was kicking the Pi due to inactivity (deauthenticated due to inactivity (timer DEAUTH/REMOVE)). With the latest firmware, the AP no longer kicks the Pi out, but the Pi itself still actively triggers a disassociation every 60 seconds.

Environment

• Hardware: Raspberry Pi Zero 2 W
• Wi-Fi Chip: BCM43430/SYN43436 (brcmfmac)
• OS: Raspberry Pi OS (Latest updates applied)
• Access Point: OpenWrt (hostapd)
• Network config: WPA2 (also tested with PMF and IPv6 completely disabled in NetworkManager)

AP Logs (OpenWrt hostapd)

Here is the exact cycle from my router's perspective. Notice the timestamps:

[20:12:22 UTC] daemon.notice: hostapd: phy0-ap0: AP-STA-DISCONNECTED 88:a2:9e:07:a6:7f
[20:12:22 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: disassociated
[20:12:22 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: authenticated
[20:12:22 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: associated (aid 1)
[20:12:23 UTC] daemon.notice: hostapd: phy0-ap0: AP-STA-CONNECTED 88:a2:9e:07:a6:7f auth_alg=open
[20:12:23 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f WPA: pairwise key handshake completed (RSN)
[20:12:25 UTC] daemon.info: dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.104 88:a2:9e:07:a6:7f rpizerow

... exactly 60 seconds later ...

[20:13:23 UTC] daemon.notice: hostapd: phy0-ap0: AP-STA-DISCONNECTED 88:a2:9e:07:a6:7f
[20:13:23 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: disassociated
[20:13:24 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: authenticated
[20:13:24 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f IEEE 802.11: associated (aid 1)
[20:13:24 UTC] daemon.notice: hostapd: phy0-ap0: AP-STA-CONNECTED 88:a2:9e:07:a6:7f auth_alg=open
[20:13:24 UTC] daemon.info: hostapd: phy0-ap0: STA 88:a2:9e:07:a6:7f WPA: pairwise key handshake completed (RSN)
[20:13:26 UTC] daemon.info: dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.104 88:a2:9e:07:a6:7f rpizerow

Attempts to resolve (Workarounds checked)

I have tried the typical community workarounds, but none of them stopped the 60-second cycle:

1. Disabled Wi-Fi power saving (wifi.powersave=2 in NetworkManager).
2. Disabled background scanning (wifi.bgscan=none in NetworkManager).
3. Disabled MAC randomization.
4. Set explicit regulatory domain via crda / wpa_supplicant.
5. Disabled Bluetooth entirely (dtoverlay=disable-bt in /boot/firmware/config.txt).
6. Configured module parameters in /etc/modprobe.d/brcmfmac.conf:
   options brcmfmac roamoff=1 fcmode=0 feature_disable=0x282000

Expected Behavior

The device should remain successfully authenticated and associated with the Access Point indefinitely without resetting the interface once per minute.

Actual Behavior

The Pi actively disassociates and instantly reassociates every ~60 seconds, which points towards a hardcoded timer either in wpa_supplicant, NetworkManager, or deep within the closed-source brcmfmac firmware blob (related to periodic scanning, keep-alives or hardware watchdogs, or GTK rekey failures).