[RFC] wpa_supplicant: add fast reconnect support

[Johannes Berg]

On Thu, 2011-04-21 at 07:38 -0700, Sam Leffler wrote:
> >> +     /*
> >> +      * If in a COMPLETED state and we were dropped for a reason
> >> +      * we can recover from directly re-join the AP without clocking
> >> +      * the state machine and/or notifying external agents.
> >> +      *
> >> +      * TODO(sleffler) guard against looping (should be only if AP is busted)
> >> +      */
> >> +     fast_reconnect =
> >> +         wpa_s->wpa_state == WPA_COMPLETED &&
> >> +         (reason_code == WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY ||
> >> +          reason_code == WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA ||
> >> +          reason_code == WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA);
> >
> > Yeah, interesting, that really should guard against looping. Probably
> > needs a variable in the BSS struct or something.
> 
> I convinced myself this was not a huge issue for us because the
> connection manager will eventually shut things down but in general it
> would be better to make this self-contained to supplicant.

Right, that makes sense.

> > I'm looking at this when we return from resume. I suppose in that case
> > it would always be one of the class2/3 frame cases though, but it could
> > be an easier case to handle wrt. looping since we "just resumed" only
> > once.
> 
> From resume status code 6 is the usual case. Especially if the sta
> does something like post a NullData frame.

Indeed.

> >> +               int ret = wpa_supplicant_fast_reconnect(wpa_s, bssid);
> >> +               if (ret == 0)
> >> +                       return;
> >> +               if (ret == -EBUSY) {
> >> +                       /*
> >> +                        * NB: EBUSY indicates a scan is already in progress.
> >> +                        * Just wait for it to complete; it will do the same
> >> +                        * reconnect work just a bit delayed (since it's likely
> >> +                        * scanning more than 1 channel).
> >> +                        */
> >> +                       wpa_printf(MSG_INFO, "Fast reconnect: piggyback on "
> >> +                                  "existing scan");
> >> +                       return;
> >> +               }
> >
> > Hm, is it really a good idea to rely on the error code? I'd think
> > drivers aren't necessarily returning a real error code since the
> > convention in wpa_s seems to be to just return -1. OTOH, -1 isn't -EBUSY
> > (it is -EPERM), so comparing is probably fine, and driver_nl80211 does
> > return the "real" error code. I suppose we should document some of this
> > here (and in the nl80211 driver so nobody breaks it) though?
> 
> nl80211-based devices use the code in sme.c which returns -EBUSY for
> this case.  I looked at changing all the driver routines to do this
> but punted.  What's there now should work for all devices; but only
> those that use the user-mode sme code will benefit.

Hmm, no, there's no scanning code in sme.c. You modified mlme.c to
return -EBUSY, but that code doesn't end up being used except for
driver_test, so you get the driver's return value here. It just ends up
working because nl80211 driver does in fact return the code.

johannes