From owner-freebsd-net@FreeBSD.ORG Tue Dec 28 08:17:30 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 15A5C106564A; Tue, 28 Dec 2010 08:17:30 +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 4652D8FC12; Tue, 28 Dec 2010 08:17:28 +0000 (UTC) Received: by bwz12 with SMTP id 12so2818908bwz.13 for ; Tue, 28 Dec 2010 00:17:28 -0800 (PST) Received: by 10.204.76.145 with SMTP id c17mr10798625bkk.52.1293524246154; Tue, 28 Dec 2010 00:17:26 -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 b17sm7942556bku.8.2010.12.28.00.17.24 (version=SSLv3 cipher=RC4-MD5); Tue, 28 Dec 2010 00:17:24 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Attilio Rao Date: Tue, 28 Dec 2010 09:15:43 +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="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201012280915.43614.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org, Adrian Chadd 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:17:30 -0000 On Tuesday 28 December 2010 01:41:39 Attilio Rao wrote: > 2010/12/27 Bernhard Schmidt : > > 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