[RFC] wpa_supplicant: add fast reconnect support
Thu Apr 21 07:38:28 PDT 2011
On Thu, Apr 21, 2011 at 7:19 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> 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? :)
I tried to be consistent with the surrounding code.
>> + ? ? /*
>> + ? ? ?* 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.
> 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
More information about the Hostap