[RFC] wpa_supplicant: add fast reconnect support

[Johannes Berg]

On Wed, 2011-03-23 at 18:07 -0700, Sam Leffler wrote:

> +	was_fast_reconnect = wpa_s->fast_reconnect;
> +	wpa_s->fast_reconnect = FALSE;

> +	wpa_s->reassociate = 1;
> +	wpa_s->fast_reconnect = 1;

That's a little inconsistent, maybe = TRUE? :)

> +	/*
> +	 * 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'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.

> +               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?

johannes