CFT/CFR, possible fix for ifconfig scan hang

[Bernhard Schmidt]

On Tuesday 28 December 2010 01:41:39 Attilio Rao wrote:
> 2010/12/27 Bernhard Schmidt <bschmidt at freebsd.org>:
> > Hi,
> > 
> > I recently received some complains about the infamous 'ifconfig scan
> > hang' issue again. Finally looking into that I noticed a bunch of
> > inconsistences, the most obvious one is that ifconfig(8) is talking
> > about doing a background scan by default, which is simply not true
> > according to the implementation.
> > 
> > Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig
> > scan' is called while a scan is already in progress, net80211 will not
> > start a new one which means that no scan flags are updated, though,
> > ifconfig will loop until it receives a notification about the scan being
> > done. This does always happen after an 'ifconfig up', because net80211
> > will move the VAP into scan state by default, with the scan flags set in
> > such a way that a scan is done until there is something to connect to.
> > This also means that no notifications about the scan being done are sent
> > to upper layers, because the scan is not finished..
> > 
> > If we successfully moved from scan to run state, how so ever, and now
> > want to call 'ifconfig scan' we're faced with another issue. Doing a
> > scan while being associated means we have to move off our current
> > channel, to do this without loosing any imported frames/information, we
> > make use of the power save feature. Now if we want to send any traffic
> > while doing the scan, the scan is temporary suspended, frames are sent,
> > then the scan is restarted after receiving a beacon and there is no
> > frame to send. For this to work though, we need to actually request a
> > background scan so appropriate flags are set and the scan is actually
> > restarted. Without this, we hang until the bgscan timer fires of at that
> > next bgscanintval.
> > 
> > I have a patch available which addresses both of the issues. It requests
> > a background scan by default and also honors the return value of
> > start_scan_locked():
> > - for head
> > http://techwires.net/~bschmidt/scan_hang_head.diff
> > - for 8-stable/8.2-*:
> > http://techwires.net/~bschmidt/scan_hang_stable.diff
> > 
> > Please test and let me know if it works, or not.
> 
> Bernard,
> thanks a lot for working on this.
> 
> There is any receipt for easilly reproduce this type of bug, or I
> should just go with 'ifconfig scan' repeteadly?
> I recall I could trigger it, but not 100% of times, so if you have
> more hints about how this problem could be reproduced, I'd be glad to
> hear.

With an wpi(4) device I was able to trigger it 100% reliably with no open AP 
available:
ifconfig wlan0 create wlandev wpi0
ifconfig wlan0 up
sleep 1
ifconfig wlan0 scan # this will hang

For background scans, wpi(4) isn't the best hardware to test with because it 
lags support for currectly (you'll only get a fireware error). So use 
something else, ath(4) works. Scan would hang if there is some light traffic 
going with enough time between frames, usally ping works.
..
wpa_supplicant -Dbsd -iwlan0 ...
# wait for device to get associated, assign ip, ..
ping somethings &
ifconfig wlan0 scan # this will hang

-- 
Bernhard