Date: Tue, 28 Dec 2010 09:16:23 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: CFT/CFR, possible fix for ifconfig scan hang Message-ID: <201012280916.23100.bschmidt@freebsd.org> In-Reply-To: <AANLkTinvMrjyeVeCjcL92XZtbgJ1-DwJOh5pMHpmtm-f@mail.gmail.com> References: <201012272024.37110.bschmidt@freebsd.org> <AANLkTinvMrjyeVeCjcL92XZtbgJ1-DwJOh5pMHpmtm-f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 December 2010 01:17:42 Brandon Gooch wrote: > On Mon, Dec 27, 2010 at 1:24 PM, Bernhard Schmidt <bschmidt@freebsd.org> 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. > > Works here, on 8.2-PRERELEASE #1 r216690 and 9.0-CURRENT #1 r216702. > > I mucked around for about an hour on both systems with varying > configurations (iwn(4) and wpi(4)), and all seemed normal and > consistently well-behaved. > > Thanks Bernhard! Thanks! -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012280916.23100.bschmidt>