BCM43455 firmware crash with concurrent STA+AP mode on kernel 6.12

[mshioji]

Describe the bug

The BCM43455 firmware crashes consistently when running in concurrent STA+AP mode on Raspberry Pi OS Trixie. The AP (on virtual interface ap0) operates successfully, but when an ESP32-based sensor device connects to it, it may trigger the firmware crash. The crash occurs intermittently - sometimes the connection succeeds, but other times it triggers the crash. (This sensor device connects to other access points without issues.)

This issue was discovered while testing whether issue #6876 (reconnection failure after sudden client disconnect) was resolved in Trixie. While that issue appears to be improved, this firmware crash makes the concurrent STA+AP configuration unusable.

On Raspberry Pi OS Bookworm with the same configuration (wlan0 as STA + ap0 as AP managed by NetworkManager), the setup has been stable in production use.

Steps to reproduce the behaviour

1. Set up Raspberry Pi OS Trixie (latest)
2. Create virtual AP interface ap0:

   sudo iw dev wlan0 interface add ap0 type __ap

3. Configure NetworkManager to run AP on ap0 while wlan0 is connected to an external WiFi network:

   sudo nmcli connection add \
     type wifi \
     ifname ap0 \
     con-name pi_ap \
     autoconnect yes \
     ssid "test-ap" \
     802-11-wireless.mode ap \
     802-11-wireless.band bg \
     802-11-wireless.channel 6 \
     ipv4.method shared \
     wifi-sec.key-mgmt wpa-psk \
     wifi-sec.psk "password123"

4. Activate the AP connection:

   sudo nmcli connection up pi_ap

5. Connect an ESP32-based device to the AP
6. The firmware crash may occur intermittently during or shortly after the connection attempt

Device (s)

Raspberry Pi 5

System

Raspberry Pi OS Trixie (latest)

Which OS and version

Raspberry Pi reference 2025-10-01
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7dadcf1fc5ce1648ab09409ab978831690c9a955, stage4

Which firmware version

2025/05/08 15:13:17
Copyright (c) 2012 Broadcom
version 69471177 (release) (embedded)

Which kernel version

Linux esec-pi-47b5 6.12.47+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux

Logs

Kernel logs showing the crash (around 551 seconds after boot):

[  551.764469] ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed
[  552.803222] ieee80211 phy0: brcmf_netdev_start_xmit: xmit rejected state=0
[  553.947570] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[  553.947662] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[  553.947707] brcmfmac: dongle trap info: type 0x7 @ epc 0x0019cec0
                                       cpsr 0x200001df spsr 0x200001bf sp 0x0025fef8
                                       lr   0x001bb06b pc   0x0019cec0 offset 0x25fea0
                                       r0   0x00215590 r1   0x00000005 r2 0x0000003c r3 0x00212b7c
                                       r4   0x00000005 r5   0x00215590 r6 0xffffff88 r7 0x00215264
[  553.947718] ieee80211 phy0: brcmf_cfg80211_dump_station: BRCMF_C_GET_ASSOCLIST failed, err=-110
[  553.947734] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  553.947737] ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-5)
[  554.363579] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  554.363588] ieee80211 phy0: brcmf_cfg80211_stop_ap: SET SSID error (-5)

Prior to crash, multiple channel setting errors (reason -52 = BCME_NOTREADY):

[  394.083016] ieee80211 phy0: brcmf_cfg80211_stop_ap: setting AP mode failed -52
[  398.008869] brcmfmac: brcmf_set_channel: set chanspec 0x100e fail, reason -52
[  398.112830] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52
[  398.212918] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52
[  398.312854] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52

Firmware information:

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

NetworkManager logs showing ap0 becomes unmanaged after firmware crash:

Oct 17 12:13:15 esec-pi-47b5 NetworkManager[861]: <info>  [1760670795.5209] device (ap0): state change: activated -> unmanaged (reason 'unmanaged-link-not-init', managed-type: 'removed')
Oct 17 12:13:16 esec-pi-47b5 NetworkManager[861]: <info>  [1760670796.0565] device (p2p-dev-ap0): state change: disconnected -> unmanaged (reason 'unmanaged-link-not-init', managed-type: 'removed')

Additional context

• The same configuration (wlan0 STA + ap0 AP) works stably on Raspberry Pi OS Bookworm
• The AP operates successfully until the firmware crash occurs
• After the crash, the ap0 interface disappears completely
• One client (ESP32 device) was connected to the AP and received DHCP address successfully before the crash
• This issue makes concurrent STA+AP mode unusable on Trixie

Workaround

Currently, the only workaround is to use Raspberry Pi OS Bookworm instead of Trixie.

[pelwell]

1. Have you tested any clients other than ESP32? I've recreated your configuration but with an Android phone as a client - no problems so far.
2. What volume of data/bandwidth is being carried by the AP?
3. Can you say approximately how long it took to fail?
4. Is the traffic just to the host of the AP or is it being relayed to another device?
5. If another device is involved, is it
   a) connected to the same AP,
   b) connected via (possibly indirectly) another AP of which the test Pi is a client, or
   c) accessible via Ethernet?

[mshioji]

@pelwell,
Thank you for looking into this issue!
You're right - this may be ESP32 or IoT device-specific. This is a challenging situation for me because I frequently build IoT systems using Raspberry Pi as an edge server with ESP32-based sensor devices. I'm currently using a workaround, but it's not ideal.
I've tried additional testing beyond what was in the original report. Here are my findings:

1. Other clients:
   I also tested with a smartphone and didn't experience any crashes. The issue seems to occur specifically with IoT devices like ESP32, particularly when they disconnect/reconnect without sending proper deauth frames (e.g., power loss scenarios).
2. Data volume:
   Very minimal - the ESP32 test device sends only timestamp data every 3 seconds.
3. Time to failure:
   Rather than a specific elapsed time, the crash appears to occur after several disconnect/reconnect cycles. When I disconnect/reconnect the ESP32 by unplugging/plugging its USB power, the crash occurs approximately 1 in 4 connection attempts. When a connection succeeds, it remains stable.
4. Traffic direction:
   In my test case, traffic flows only from the ESP32 device to the AP (one-way).
5. Network topology:
   Simple configuration - just the ESP32 device connecting directly to the AP. No other devices involved in the test scenario.