Raspberry Pi 5: Persistent brcmfmac scan failures (-52) following SAE external-auth error (-22)

Start with cfg80211_external_auth_request(), brcmf_run_escan(), and brcmf_cfg80211_scan(), then compare the event ordering around upstream commit 145e565664c7979e21f691ee752ad459af6b12fb and the reported UML/KUnit tests. Reproduce the external-auth owner-loss case in those tests and determine whether the missing owner is the initiating failure or a consequence. Done means identifying the causal event sequence, preserving the original firmware status before it becomes -52, and validating any recovery change against the hardware scenario.

Describe the bug

On 30 October 2026, a Raspberry Pi 5 running Debian 13 (trixie) lost its Wi-Fi connection after approximately two days of uptime.

During the subsequent reconnection attempt, external SAE authentication failed with -22. Afterwards, Wi-Fi scans repeatedly failed with -52, preventing NetworkManager from restoring the connection.

The scan failures persisted overnight. Reloading the Broadcom driver modules restored normal operation immediately, without rebooting the Raspberry Pi or changing the Wi-Fi configuration.

The failure occurred with WPA3-SAE on a WPA2/WPA3 transition-mode network. WPA3 had worked successfully before the incident and worked again after the driver reload.

A subsequent test disabling SAE_EXT resulted in a working WPA2 connection. Whether this prevents the original failure over longer periods remains unknown.

The primary concern is that the driver remained unable to perform Wi-Fi scans and did not recover automatically.

Steps to reproduce the behaviour

The failure has not yet been reproduced deterministically.

Observed conditions:

1. Raspberry Pi 5 with BCM4345/6 (BCM43455), using the internal SDIO Wi-Fi interface.
2. Kernel 6.18.50+rpt-rpi-2712, firmware 7.45.265.
3. NetworkManager with a WPA-PSK profile connected to a WPA2/WPA3 transition-mode SSID.
4. Two access points broadcast the same 2.4 GHz SSID.
5. The connection uses WPA3-SAE (key_mgmt=SAE).
6. After approximately two days of uptime, the connection was lost.
7. The subsequent authentication attempt failed with -22.
8. Wi-Fi scanning then repeatedly failed with -52 until the driver modules were reloaded.

Recovery commands:

sudo modprobe -r brcmfmac_cyw brcmfmac
sudo modprobe brcmfmac

These commands restored normal operation without a system reboot.

Device (s)

Raspberry Pi 5

System

Device: Raspberry Pi 5, 8 GB, ARM64

Operating system: Debian GNU/Linux 13.7 (trixie)

Kernel: 6.18.50+rpt-rpi-2712

Kernel package: 1:6.18.50-1+rpt1

Published Raspberry Pi kernel source commit: cff533aec2fa601846766b32ff57204e0a61bed7

Wi-Fi chipset: Broadcom BCM4345/6 (BCM43455), SDIO

Driver: brcmfmac, brcmfmac_cyw

Wi-Fi firmware: 7.45.265 (28bca26 CY), dated 29 August 2023, FWID 01-b677b91b

Firmware package: firmware-brcm80211 1:20260519-1~bpo13+1+rpt1

NetworkManager: 1.52.1-1+rpt4

wpa_supplicant: 2:2.10-24+rpt3

Board firmware version (vcgencmd version):

2026/05/11 12:20:02
Copyright (c) 2012 Broadcom
version 66f33f7e (release) (embedded)

Original driver configuration:
options brcmfmac roamoff=1 feature_disable=0x282000

Wi-Fi power saving was disabled.

The network consists of two access points broadcasting the same 2.4 GHz SSID in WPA2/WPA3 transition mode.

Logs

The following messages were retained from the incident report.

All timestamps are Europe/Berlin local time (CET).

30 October 2026, 21:38:43 – Initial disconnect

wlan0: CTRL-EVENT-DISCONNECTED bssid=<redacted> reason=0 locally_generated=1

21:38:51 – Failed reconnection

wlan0: Trying to associate with <redacted> (SSID=<redacted> freq=2432 MHz)
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16

brcmf_cyw_notify_ext_auth_req: Ext Auth request to supplicant failed (-22)
brcmf_fweh_event_worker: event handler failed (187)
brcmf_run_escan: error (-52)
brcmf_cfg80211_scan: scan error (-52)

Subsequent repeated failures

wlan0: CTRL-EVENT-SCAN-FAILED ret=-52

NetworkManager repeatedly attempted reconnection, but failed with supplicant-timeout and ssid-not-found.

Scan errors continued approximately every two minutes until the driver reload on 31 October 2026.

31 October 2026, approximately 08:17 – Recovery

The driver was reloaded successfully. Firmware initialization reported:

brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b

After reloading, WPA3-SAE authentication and Wi-Fi scanning worked again.

No new -52 scan errors were observed in the subsequent short tests.

Evidence limitation: These are retained excerpts, not complete original journal exports.

Additional context

Source-code investigation

The relevant published Raspberry Pi kernel source was examined.

The investigation identified:

1. The observed external-authentication error -22 is consistent with cfg80211_external_auth_request() rejecting a request because conn_owner_nlportid is zero.

2. In the normal FWIL error path, negative firmware status values can be translated to -EBADE (-52). The original firmware status was not captured, so its precise meaning is unknown.

3. The scan-start error path clears the host BUSY/request state. Therefore, a permanently set BUSY bit alone does not explain the repeated failures.

4. Upstream commit 145e565664c7979e21f691ee752ad459af6b12fb addresses a cfg80211 event-ordering race that can clear connection state belonging to a newer connection.

https://github.com/torvalds/linux/commit/145e565664c7979e21f691ee752ad459af6b12fb

Isolated UML/KUnit tests reproduced one owner-loss scenario and confirmed that the upstream commit prevents it in that test. However, these tests did not reproduce the actual hardware incident or demonstrate recovery from the persistent -52 errors.

The causal relationship between the initial disconnect, external SAE authentication failure and subsequent scan failures remains unproven.

WPA2 workaround

On 31 October, the driver configuration was changed from:

roamoff=1 feature_disable=0x282000

to:

roamoff=1 feature_disable=0x2282000

The additional bit disables SAE_EXT in the investigated kernel version.

After reloading the driver, the Raspberry Pi connected successfully using WPA2-PSK with PMF enabled. Subsequent ping and scanning tests succeeded.

A longer stability test is ongoing. This does not yet establish that disabling SAE_EXT prevents the original failure.

Related issues

• https://github.com/raspberrypi/linux/issues/7634
• https://github.com/raspberrypi/bookworm-feedback/issues/220

Questions for maintainers

1. Is this failure pattern known for BCM43455 firmware 7.45.265?
2. How can the original firmware error status be captured before it is translated to -52?
3. Could the missing connection owner during external authentication be related to a known cfg80211 event-ordering race?
4. Are there existing fixes or recovery mechanisms for persistent scan failures?
5. Which additional diagnostics would be most useful if the issue occurs again?

Limitations

The original firmware status and complete event chronology are unavailable.

No deterministic hardware reproduction or vanilla upstream-kernel test has been performed.

The installed kernel binaries have not been independently verified against the published source package.

The source-code investigation and isolated tests were assisted by OpenAI Codex. The findings were reviewed before submission.