Date: Mon, 27 Dec 2010 18:17:42 -0600 From: Brandon Gooch <jamesbrandongooch@gmail.com> To: Bernhard Schmidt <bschmidt@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, freebsd-net@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: CFT/CFR, possible fix for ifconfig scan hang Message-ID: <AANLkTinvMrjyeVeCjcL92XZtbgJ1-DwJOh5pMHpmtm-f@mail.gmail.com> 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
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! -Brandon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinvMrjyeVeCjcL92XZtbgJ1-DwJOh5pMHpmtm-f>