Date: Tue, 28 Dec 2010 09:15:43 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-net@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: CFT/CFR, possible fix for ifconfig scan hang Message-ID: <201012280915.43614.bschmidt@freebsd.org> In-Reply-To: <AANLkTi=ZLpOeHzA5EcFtM1tpGPTg3ft6cDjudUaY8Qca@mail.gmail.com> References: <201012272024.37110.bschmidt@freebsd.org> <AANLkTi=ZLpOeHzA5EcFtM1tpGPTg3ft6cDjudUaY8Qca@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 December 2010 01:41:39 Attilio Rao wrote: > 2010/12/27 Bernhard Schmidt <bschmidt@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012280915.43614.bschmidt>