From owner-freebsd-net@FreeBSD.ORG Tue Dec 28 08:18:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7151B106566B for ; Tue, 28 Dec 2010 08:18:08 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03BDA8FC0A for ; Tue, 28 Dec 2010 08:18:07 +0000 (UTC) Received: by bwz12 with SMTP id 12so2819100bwz.13 for ; Tue, 28 Dec 2010 00:18:07 -0800 (PST) Received: by 10.204.1.132 with SMTP id 4mr746326bkf.136.1293524285434; Tue, 28 Dec 2010 00:18:05 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-065-050-231.pools.arcor-ip.net [88.65.50.231]) by mx.google.com with ESMTPS id j11sm8071551bka.12.2010.12.28.00.18.03 (version=SSLv3 cipher=RC4-MD5); Tue, 28 Dec 2010 00:18:04 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Brandon Gooch Date: Tue, 28 Dec 2010 09:16:23 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: <201012272024.37110.bschmidt@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012280916.23100.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: CFT/CFR, possible fix for ifconfig scan hang X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 08:18:08 -0000 On Tuesday 28 December 2010 01:17:42 Brandon Gooch wrote: > On Mon, Dec 27, 2010 at 1:24 PM, 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. > > 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