[RFC] wpa_supplicant: add fast reconnect support

[Dan Williams]

On Tue, 2012-01-03 at 09:57 -0800, Sam Leffler wrote:
> 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.

So CurrentBSS should be reflected through PropertiesChanged when
wpas_notify_bssid_changed() gets called, which eventually checks
wpa_s->current_bss for the value to send out in the PC event.  A quick
audit doesn't show anywhere that current_bss is set to NULL that doesn't
also call wpas_notify_bssid_changed() but I didn't look too deeply.

One way to fix this stuff for sure is to use setter functions that
automatically send out the change notification when called.  Like
replacing every occurrance of wpa_s->current_bss = XXXX with
wpa_supplicant_set_current_bss (struct wpa_supplicant *wpa_s, struct
wpa_bss *bss); and checking whether the new bss matches the old BSS and
if not, sending the change event.  We'd also need the same for
CurrentNetwork (wpas_notify_network_changed()) and a few other things to
start with.

Dan


> 
> >
> > 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
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap