Date: Mon, 17 Jan 2011 21:32:52 +0100 From: Bernhard Schmidt <bschmidt@techwires.net> To: freebsd-net@freebsd.org Subject: Re: CFT/CFR, possible fix for ifconfig scan hang Message-ID: <201101172132.53027.bschmidt@techwires.net> In-Reply-To: <201012272024.37110.bschmidt@freebsd.org> References: <201012272024.37110.bschmidt@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, no objections so far. If non arise till this weekend, I going to commit this. On Monday 27 December 2010 20:24:36 Bernhard Schmidt wrote: > 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. > > Thanks > -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101172132.53027.bschmidt>