Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Dec 2010 20:24:36 +0100
From:      Bernhard Schmidt <bschmidt@freebsd.org>
To:        freebsd-net@freebsd.org
Cc:        Attilio Rao <attilio@freebsd.org>, Adrian Chadd <adrian@freebsd.org>
Subject:   CFT/CFR, possible fix for ifconfig scan hang
Message-ID:  <201012272024.37110.bschmidt@freebsd.org>

next in thread | raw e-mail | index | archive | help
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?201012272024.37110.bschmidt>