AP mode re-connection issue with IoT devices using ESP32

Start by reproducing the ESP32 power-loss scenario and monitoring iw dev ap0 station dump, using the listed Raspberry Pi OS, kernel, brcmfmac driver, and firmware versions. Compare the older and newer systems, including the NetworkManager and hostapd/dnsmasq setups described. Done means the stale station entry no longer prevents reconnection, or the regression is narrowed to the kernel, driver, or firmware change.

Describe the bug

Hello,

I am reporting a persistent issue with my Raspberry Pi's AP mode connection, with IoT devices using ESP32.

Problem Description:
When an ESP32 device disconnects from the Raspberry Pi's Wi-Fi AP (e.g., by sudden power loss, which prevents deauthentication frames from being sent), the AP continues to list the ESP32 as a connected station for an extended period (around 27 - 70 seconds) according to $ iw dev ap0 station dump. If the ESP32 is powered on again during this window, it will never reconnect to the AP. The ESP32's connection attempts are completely ignored, and the AP interface needs to be manually reset with $ nmcli connection up ap0 to re-connect.

Observed Behavior on Older System (Comparison):
On an older OS version, when an ESP32 disconnected without a deauthentication frame, $ iw dev ap0 station dump would initially keep showing the disconnected ESP32 for about 35 seconds, which is a similar behavior. Crucially, if the ESP32 attempted to reconnect during this period, the AP would "proactively clear" the old station entry after approximately 6 seconds (from the new connection attempt), and then successfully establish a new connection within another 5 seconds. This "proactive clearing" behavior allowed for stable and quick re-connections, demonstrating intelligent handling of clients that don't send deauthentication frames. This feature appears to be lost in newer versions.

Steps to reproduce the behaviour

1. setup Raspberry Pi as an AP.
2. connect IoT device using ESP32 (or something) to Raspberry Pi AP with WiFi.
3. turn off ESP32 device (pull plug out from USB Power)
4. power on ESP32 device again in "few" seconds.
5. -> ESP32 Device will Never reconnect to Pi AP (forever).
6. nmcli connection up pi_ap needed to reconnect.

• if we wait for 90sec before 4. power on again, ESP32 device is able to connect.
• on older version of Raspberry Pi OS, ESP32 re-connection goes smoothly.

here is the AP configurations with dummy password:

  $ sudo nmcli connection add \
  type wifi \
  ifname ap0 \
  con-name pi_ap \
  autoconnect yes \
  ssid pi_ap \
  802-11-wireless.mode ap \
  802-11-wireless.band bg \
  802-11-wireless.channel 6 \
  ipv4.method shared \
  ipv4.never-default yes \
  wifi-sec.key-mgmt wpa-psk \
  wifi-sec.pairwise ccmp \
  wifi-sec.group ccmp \
  wifi-sec.proto rsn \
  wifi-sec.psk "p@ssw0rd"

Device (s)

Raspberry Pi 4 Mod. B and Raspberry Pi 5

System

"NG" System (Newer Kernel/Driver/Firmware - observed on recent Bookworm):

OS: Debian GNU/Linux 12 (bookworm) (or Bullseye after relevant updates)
Kernel: Linux riot-b7b7 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
brcmfmac Driver: srcversion: 9F4DA02FA39ED55C624CB1F
brcmfmac Firmware: version 7.45.265 (28bca26 CY) FWID 01-b677b91b (Aug 29 2023)

"OK" System (Older Kernel/Driver/Firmware):

OS: Debian GNU/Linux 11 (bullseye)
Kernel: Linux qmgr-4e43 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
brcmfmac Driver: srcversion: 0EA2B0D5930C402A5A7CD6A
brcmfmac Firmware: version 7.45.241 (1a2f2fa CY) FWID 01-703fd60 (Nov 1 2021)

Logs

Log of “old” operating system. (In this case, the wlan0 interface is being used.)
issue $ iw dev wlan0 station dump every one second to monitor.

• Please note this is the OK case:

kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump
Station e0:e2:e6:0c:2f:14 (on wlan0)                                    // <-- this is the old connection kept by system.
	inactive time:	17000 ms
	rx bytes:	5169
	rx packets:	61
	tx bytes:	10789
	tx packets:	81
	tx failed:	0
	tx bitrate:	54.0 MBit/s
	rx bitrate:	6.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	WMM/WME:	yes
	TDLS peer:	yes
	DTIM period:	2
	beacon interval:100
	short slot time:yes
	connected time:	59 seconds
	current time:	1748672363850 ms
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump  // <-- connection reset happened here in "OLD" system
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump  //  but this will not happen in latest Bookworm.
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump
Station e0:e2:e6:0c:2f:14 (on wlan0)                                 // <-- new connection established.
	inactive time:	0 ms
	rx bytes:	1264
	rx packets:	7
	tx bytes:	10766
	tx packets:	74
	tx failed:	0
	tx bitrate:	54.0 MBit/s
	rx bitrate:	6.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	WMM/WME:	yes
	TDLS peer:	yes
	DTIM period:	2
	beacon interval:100
	short slot time:yes
	connected time:	0 seconds
	current time:	1748672368867 ms
kuroneko@qmgr-4e43:~ $ iw dev wlan0 station dump

Additional context

Troubleshooting Steps Taken:
I tried configuring the AP manually by setting ap0 to be unmanaged by NetworkManager and then directly setting up hostapd and dnsmasq for ap0 (while wlan0 remained managed by NetworkManager for STA mode). However, the result was the same.

It seems this behavior is consistent across different Raspberry Pi OS releases like upgraded-bullseye and Bookworm, once these newer components are in place.

Conclusion:
These observations may probably implies this regression is caused by specific updates within the Linux kernel, the brcmfmac Wi-Fi driver, or its associated firmware?
The "proactive clearing" mechanism for old station entries (which allowed new connections to override old, un-deauthenticated ones) that was present in older versions seems to be absent in the latest versions.

Any insights or assistance, especially from those familiar with this area, would be greatly appreciated.
Thank you for your time and consideration.