[RFC] wpa_supplicant: add fast reconnect support

[Sam Leffler]

On Sun, Jan 1, 2012 at 7:54 AM, Jouni Malinen <j at w1.fi> wrote:

> On Wed, Dec 21, 2011 at 03:53:21PM -0800, Sam Leffler wrote:
> >
> http://git.chromium.org/gitweb/?p=chromiumos/third_party/autotest.git;a=blob;f=server/site_tests/network_WiFiRoaming/006BeaconLoss;h=35e1c01b952a71ba86c5c977ad5ddd22b676c448;hb=HEAD
> >
> > The issue is that when the AP is silently taken down (i.e. w/o sending
> > deauth) the client trys to reauth but fails--but never notifies the
> > connection manager over D-bus so it thinks it's still associated.  I
> > believe when I split the state machine for fast reconnect I had to handle
> > this case in sme.c for reauth failure.
>
> Hmm.. I was unable to reproduce this. I tested this with ath9k and
> couple of seconds after turning off the AP, wpa_supplicant received an
> nl80211 event indicating deauthentication and that resulted in
> PropertiesChanged notification in D-Bus with State changing to
> disconnected.
>

There is no signal to indicate CurrentBSS is nil.  I can send you a log
demonstrating the problem if you care.


>
> This case should not really have triggered the fast reconnection attempt
> since the AP did not send any Deauthentication frame. However, it looks
> like the locally generated deauth event with reason 4 was interpreted as
> a Deauthentication done by the AP. I'll see how to fix this, but
> regardless, I don't see how this would have skipped the disconnection
> notification to the connection manager.


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.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20120103/d87dad8d/attachment.htm