wpa_supplicant: STA stranded disconnected after failed BTM transition, expired candidate list swallows reconnect scan

[Tyler Busby]

Hi,

wpa_supplicant 2.12 (also checked against main at 4bd12dcff) can leave a
station disconnected indefinitely after an AP-initiated BSS transition fails.
In our case one laptop sat disconnected for 24 days, and today the bug
reproduced on 2 out of 2 boots, within about a minute of connecting.

Setup: Intel iwlwifi (nl80211, userspace SME), SAE/PMF network, single ESS
with several APs that send BTM requests with validity_interval=0.

Sequence (from a -d log, trimmed):

  17:42:51.404094 WNM: BSS Transition Management Request:
dialog_token=1 request_mode=0x1 disassoc_timer=0 validity_interval=0
  17:42:51.404222 WNM: Candidate list valid for 0 ms
  17:42:51.408605 wlp3s0: WNM: Transition to BSS a8:9c:6c:5a:58:32
based on BSS Transition Management Request (old BSSID
a8:9c:6c:64:41:0e after_new_scan=1)
  17:42:51.409882 WNM: Issuing connect
  17:42:51.443867 wlp3s0: State: COMPLETED -> AUTHENTICATING
  17:42:56.566697 wlp3s0: SME: Authentication timeout
  17:42:56.592013 wlp3s0: Added BSSID a8:9c:6c:5a:58:32 into ignore
list, ignoring for 10 seconds
  17:42:56.592024 wlp3s0: Consecutive connection failures: 1 -->
request scan in 100 ms
  17:42:56.592036 wlp3s0: State: AUTHENTICATING -> DISCONNECTED
  17:42:56.692271 wlp3s0: State: DISCONNECTED -> SCANNING
  17:42:56.697172 Scan requested (ret=0) - scan timeout 30 seconds
  17:42:58.460426 nl80211: Received scan results (36 BSSes)
  17:42:58.462145 wlp3s0: New scan results available (own=1 ext=0)
  17:42:58.462177 wlp3s0: WNM: Process scan results for BSS Transition
Management
  17:42:58.462181 WNM: Previously stored BSS transition candidate list
is not valid anymore - drop it
  17:42:58.462190 wlp3s0: Radio work 'scan'@0x62417d8e82a0 done in
1.769563 seconds
  [nothing further from the station state machine; no scan is scheduled again]

The 36 BSSes include the original AP (a8:9c:6c:64:41:0e) and other APs in the
same ESS, all acceptable. Without debug logging the station ends up in
DISCONNECTED with Scanning=false. A D-Bus Scan() or Reassociate() recovers it
immediately.

What I believe happens (line numbers from main):

1. The failed transition leaves wnm_dialog_token / the candidate list in place.
   wnm_btm_reset() runs on COMPLETED, INACTIVE and INTERFACE_DISABLED
   (wpa_supplicant.c:1335), but not on DISCONNECTED.

2. The reconnect scan's results go through _wpa_supplicant_event_scan_results(),
   which calls wnm_scan_process(wpa_s, false) first (events.c:2874).

3. Because validity_interval was 0, wnm_cand_valid_until is before
   scan_trigger_time, so wnm_scan_process() takes the "not valid anymore"
   branch (wnm_sta.c:1213) to send_bss_resp_fail. That path rejects the request
   and resets the BTM state, but returns 1.

4. The caller treats > 0 as "WNM consumed these results" and jumps to
   scan_work_done. That skips network selection, and with it the
   no-network-selected path that would reschedule a scan. Nothing else
   requests a scan while DISCONNECTED, so the station stays down.

The same return value seems harmless while still associated, since the
station simply stays on its current AP. It only strands the station when the
BTM request itself caused the disconnect.

Possible fix, untested and offered for discussion: send_bss_resp_fail
should return 0, so that a rejected or dropped BTM request falls through to
normal scan processing. Alternatively, only the expired-candidate branch could
return 0, or the BTM state could also be reset on a transition-initiated
connection failure.

--- a/wpa_supplicant/wnm_sta.c
+++ b/wpa_supplicant/wnm_sta.c
@@ send_bss_resp_fail:
  wnm_btm_reset(wpa_s);

- return 1;
+ /* Nothing was acted on; let the caller run normal network selection so
+ * a station left disconnected by a failed transition reconnects. */
+ return 0;
 }

Workaround in use: disable_btm=1.

I can provide the full -d log if useful.

Thanks,
Tyler