On Sun, Jan 1, 2012 at 7:54 AM, Jouni Malinen <span dir="ltr">&lt;<a href="mailto:j@w1.fi">j@w1.fi</a>&gt;</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>
&gt; <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>

&gt;<br>
&gt; The issue is that when the AP is silently taken down (i.e. w/o sending<br>
&gt; deauth) the client trys to reauth but fails--but never notifies the<br>
&gt; connection manager over D-bus so it thinks it&#39;s still associated.  I<br>
&gt; believe when I split the state machine for fast reconnect I had to handle<br>
&gt; 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&#39;ll see how to fix this, but<br>
regardless, I don&#39;t see how this would have skipped the disconnection<br>
notification to the connection manager.</blockquote><div><br></div><div>I don&#39;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>