On Sun, Jan 1, 2012 at 7:54 AM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi">j@w1.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Dec 21, 2011 at 03:53:21PM -0800, Sam Leffler wrote:<br>
> <a href="http://git.chromium.org/gitweb/?p=chromiumos/third_party/autotest.git;a=blob;f=server/site_tests/network_WiFiRoaming/006BeaconLoss;h=35e1c01b952a71ba86c5c977ad5ddd22b676c448;hb=HEAD" target="_blank">http://git.chromium.org/gitweb/?p=chromiumos/third_party/autotest.git;a=blob;f=server/site_tests/network_WiFiRoaming/006BeaconLoss;h=35e1c01b952a71ba86c5c977ad5ddd22b676c448;hb=HEAD</a><br>
><br>
> The issue is that when the AP is silently taken down (i.e. w/o sending<br>
> deauth) the client trys to reauth but fails--but never notifies the<br>
> connection manager over D-bus so it thinks it's still associated. I<br>
> believe when I split the state machine for fast reconnect I had to handle<br>
> this case in sme.c for reauth failure.<br>
<br>
</div>Hmm.. I was unable to reproduce this. I tested this with ath9k and<br>
couple of seconds after turning off the AP, wpa_supplicant received an<br>
nl80211 event indicating deauthentication and that resulted in<br>
PropertiesChanged notification in D-Bus with State changing to<br>
disconnected.<br></blockquote><div><br></div><div>There is no signal to indicate CurrentBSS is nil. I can send you a log demonstrating the problem if you care.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This case should not really have triggered the fast reconnection attempt<br>
since the AP did not send any Deauthentication frame. However, it looks<br>
like the locally generated deauth event with reason 4 was interpreted as<br>
a Deauthentication done by the AP. I'll see how to fix this, but<br>
regardless, I don't see how this would have skipped the disconnection<br>
notification to the connection manager.</blockquote><div><br></div><div>I don't agree; on beacon loss you should first probe the AP before dropping into a full scan. If this is done with a NullData frame then going straight to a full scan makes sense. Otherwise a failed direct reconnect will take a few ms and is the right thing to do before incurring the cost of the scan.</div>
<div><br></div><div>-Sam</div></div>