Endless assoc/disassoc loop due to wpa_driver_nl80211_authenticate

[Ben Greear]

On 11/09/2011 06:54 AM, Jouni Malinen wrote:
> On Thu, Nov 03, 2011 at 09:55:51PM -0700, Ben Greear wrote:
>> The wpa_driver_nl80211_authenticate method has some retry code
>> that hits when the kernel returns -EALREADY:
>
>> 		if (ret == -EALREADY&&  count == 1&&  params->bssid&&
>> 		!params->local_state_change) {
>> 			/*
>> 			 * mac80211 does not currently accept new
>> 			 * authentication if we are already authenticated. As a
>> 			 * workaround, force deauthentication and try again.
>> 			 */
>
>> The problem is, that deauth call will cause a DEAUTH event shortly after,
>> which will cause the station to deauth itself again.  This causes an endless loop of
>> auth/deauth when you have lots of VIFS in non-WPA mode.
>
> That DEAUTH event is supposed to get ignored..

I know, but for some reason, it is not when I have 130 or so
virtual stations.  I can send you logs if you want....it's 100%
reproducible for me.

>> Any idea why this was put in to begin with?
>
> That comment in the code above should explain the reason.. mac80211 (or
> cfg80211; don't remember which) was (and for many parts, still is) quite
> picky about the state in which some operations are run and the only way
> wpa_supplicant could work around some connection issues was to
> forcefully clear association and authentication state.

 From what I saw, if you just return an error here, then the calling
code deals with the error and restarts authentication properly.

> It could be possible to avoid these by making wpa_supplicant track the
> authenticated state separately, but I'm not sure whether it is really
> worth the extra complexity. Other approach could be to try to just
> skip the authentication step based on EALREADY error and move to
> association. That may have some other issues, though, so any change in

I tried just returning a success if we got EALREADY, but that did not
work.

> this area will require quite a bit of review and testing (including
> testing with number of older kernel versions).

I'm guessing this error case happens very rarely in normal
circumstances, so I'm not sure of any good way to test this
without my specific test case that sees this problem.

If you're happy with the current code, then lets just leave
it as is..I'll carry a small #if 0 patch in my tree to disable that
retry code.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com