On 27/08/2025 14:09, Bjoern A. Zeeb wrote:
On Wed, 27 Aug 2025, Andriy Gapon wrote:
It seems that on the latest CURRENT, ifconfig wlan0 scan, executed while
associated, just hangs indefinitely.
I recall that it used to work in the past (possibly losing association while
scanning).
ifconfig's stack looks like it's waiting to receive something (over netlink?):
PID TID COMM TDNAME KSTACK
43416 100469 ifconfig - mi_switch+0x188
sleepq_switch+0xec sleepq_catch_signals+0x2bc sleepq_wait_sig+0xc _sleep+0x260
soreceive_generic_locked+0x1cc soreceive_generic+0xa8 soreceive+0x48
dofileread+0x74 kern_readv+0x4c sys_read+0x88 do_el0_sync+0x618
handle_el0_sync+0x4c
Looks like it regressed in April/May time frame.
Just in case, the hardware is rtwn on USB.
We used to leak BGSCANs even when disabled (32af70fae827ec) but with rtwn
that shouldn't be the problem as it is enabled by default if I do not
misremeber.
But the problem isn't new; even with iwm years ago scans sometimes used
to hang. ^c works, sometimes with multiple persuasions and waiting a
few seconds.
What I see now is pretty consistent.
ifconfig always hangs and it is always interruptible with ^C.
I enabled scan debug and I can see that the command actually initiates a scan:
wlan0: ieee80211_scanreq: vap 0xffffa00013246000 iv_state 0x5 (RUN) flags 0x13
duration 0x7fffffff mindwell 0 maxdwell 0 nssid 0
wlan0: ieee80211_swscan_start_scan_locked: active scan, duration 2147483647
mindwell 0 maxdwell 0, desired mode auto, append, nopick, once
...
wlan0: ieee80211_swscan_add_scan: chan 11g min dwell met (3156845617 >
18446744072571429922)
wlan0: scan_mindwell: called
wlan0: scan_curchan_task: loop start; scandone=0, scanstop=0, ss_iflags=0x21,
ss_next=3, ss_last=32
wlan0: scan_curchan_task: chan 11g -> 7g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_curchan_task: waiting
wlan0: ieee80211_swscan_cancel_anyscan: pause active scan
wlan0: scan_curchan_task: loop start; scandone=0, scanstop=1, ss_iflags=0x2c,
ss_next=4, ss_last=32
wlan0: scan_end: out
wlan0: scan_end: done, [ticks 3156845740, dwell min 20 scanend 1009361848]
<END>
And I see the scan discovering some APs etc.
But then there is this: scandone=0, scanstop=1.
If I compare to a scan done while not associated, the message at the very end
should be scandone=1, scanstop=1 and there should be a list of discovered APs
and then there should be this message:
wlan0: notify scan done.
Oh, and I see that "scan while associated" stops after examining just a few
channels comparing to a "normal scan".
Normal scan reports:
wlan0: scan_curchan_task: chan 36v -> 1g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 1g -> 6g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 6g -> 11g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 11g -> 7g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 7g -> 13g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 13g -> 52a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 52a -> 56a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 56a -> 60a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 60a -> 64a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 64a -> 36a [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 36a -> 40a [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 40a -> 44a [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 44a -> 48a [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 48a -> 2g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 2g -> 3g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 3g -> 4g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 4g -> 5g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 5g -> 8g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 8g -> 9g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 9g -> 10g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 10g -> 12g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 12g -> 100a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 100a -> 104a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 104a -> 108a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 108a -> 112a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 112a -> 116a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 116a -> 120a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 120a -> 124a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 124a -> 128a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 128a -> 132a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 132a -> 136a [passive, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 136a -> 140a [passive, dwell min 20ms max
18446638520593285320ms]
Scan while associated reports only:
wlan0: scan_curchan_task: chan 36v -> 1g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 1g -> 6g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 6g -> 11g [active, dwell min 20ms max
18446638520593285320ms]
wlan0: scan_curchan_task: chan 11g -> 7g [active, dwell min 20ms max
18446638520593285320ms]
From a quick look at the code it seems that ieee80211_start_pkt() would call
ieee80211_cancel_anyscan().
But somehow the canceled scan is not made known to ifconfig.
Maybe ideally it should even auto-continue...
What you are saying is basically that there's more paths we leak some
scan state most likely and will scan "forever" without scanning.
If you try to scan from wpa_cli you get a BUSY back?
Yes:
# wpa_cli scan
Selected interface 'wlan0'
FAIL-BUSY
If you could break to ddb when in that state and do
show all vaps
show com /a <vap pointer>
I think it is (from memory) and gather the full state, that would be
great, at least to see if I am correctly guessing.
Let me try to check these things later, if still needed.
--
Andriy Gapon
