Persistent STA Reconnection Failure After CTRL-EVENT-CHANNEL-SWITCH (wpa_supplicant 2.10 + BCM43430)

[Aswathi Sivalingam]

Hi all,

I'm debugging a persistent STA reconnection failure observed in
production testing on an embedded Linux device using wpa_supplicant
v2.10 and the BCM43430 (CYFMAC43430) Wi-Fi chipset.

Summary:

    After a power cycle (both device and AP rebooted), the STA
interface (wlan0) fails to reconnect to a saved SSID. The failure
persists for hours, with repeated association attempts, until the
device is manually rebooted.
    The logs show a rare CTRL-EVENT-CHANNEL-SWITCH event immediately
before the failure loop begins. We suspect this might trigger an
unrecoverable path in the supplicant or driver.

Environment:

    - SoC: i.MX6UL
    - Kernel: 5.15.71 (Yocto Kirkstone)
    - Chipset: BCM43430 (CYFMAC43430 over SDIO)
    - Driver: cyfmac43430-sdio
    - wpa_supplicant: v2.10 (with NetworkManager)
    - AP+STA concurrency: yes (interfaces: wlan-ap, wlan0)
    - Regulatory domain: GB ➝ DE during association

Relevant Log Excerpt:

    wlan0: CTRL-EVENT-DISCONNECTED reason=0 locally_generated=1
    wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
    wlan0: Trying to associate with SSID 'ASUS'
    wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
    wlan0: CTRL-EVENT-CHANNEL-SWITCH freq=2447 ht_enabled=1
    NetworkManager: ip-config failed; device state change to disconnected
    wlan0: CTRL-EVENT-DISCONNECTED reason=3 locally_generated=1
    ...
    [This loop repeats until device is rebooted]

Observations:

    - In normal cases, changing the AP channel or toggling AP state
does not cause issues — the STA adapts and reconnects.
    - However, this specific failure only occurs in production and is
not easily reproducible.
    - I have never seen CTRL-EVENT-CHANNEL-SWITCH under normal
conditions — it only appears in the failure case.
    - AP+STA always operate on the same channel.

Questions:

    1. Could CTRL-EVENT-CHANNEL-SWITCH trigger a code path in
wpa_supplicant or the driver that leads to a persistent reconnection
failure?
    2. Are there known issues in v2.10 related to channel switching or
regulatory domain transitions (especially in AP+STA mode)?
    3. Is there a way to reliably simulate a channel switch on the AP
(e.g. via hostapd) to help reproduce this?
    4. Based on the logs above, do you see any signs that might point
to a root cause?

Any advice or pointers (or confirmation this is known behavior) would
be much appreciated.

---
Thanks,
Aswathi Sivalingam