Re: [RFC] cfg80211: Fix handling of previous_auth deauth

From: Paul Stewart <pstew@chromium.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] cfg80211: Fix handling of previous_auth deauth
Date: Wed, 8 Jun 2011 04:48:51 -0700	[thread overview]
Message-ID: <BANLkTikc-6hwZwT4Qt-dB-qBkwxEWLwrkg@mail.gmail.com> (raw)
In-Reply-To: <1307533479.3961.13.camel@jlt3.sipsolutions.net>

On Wed, Jun 8, 2011 at 4:44 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> [you should send as text, the list won't accept html]
>
>>         Maybe I'm confused -- what's "this issue"?
>
>> Sorry.  I covered the issue in a previous post but it wasn't threaded
>> in.   Here's a summary:
>>
>>
>> If you read the IEEE docs just right, they say that if an AP believes
>> a STA is authenticated, but it receives an AUTH request, it should
>> send a DEAUTH downstream with PREV_AUTH_NOT_VALID.  Some APs actually
>> do this.  The STA and AP can fall out of sync, eg, if the STA reboots
>> unexpectedly.  What happens then is that the a mac80211 STA will send
>> an AUTH, and get a DEAUTH  which will clear authtry_bssess[].
>>  mac80211 keeps retrying, though, and the second time the AP sends a
>> successful AUTH response and marks the STA authenticated again.
>>  Meanwhile cfg80211 doesn't have any state in authtry_bsses[] for the
>> AP so it drops the successful reply on the floor.  Thus the state
>> mismatch perpetuates.
>
>
> Right, makes sense.
>
>>         It seems mac80211 shouldn't pass such up since it isn't
>>         actually
>>         connected. But then we just pass them up and rely on cfg80211
>>         to sort it
>>         out. Why do we even attempt to remove something from
>>         authtry_bsses when
>>         receiving a deauth frame? This only makes sense when we sent
>>         it
>>         ourselves and want to abort the authentication that way I
>>         guess?
>>
>> It's a little confusing to me that the same function is in charge of
>> outgoing and incoming packets, but yes, I see no point in removing
>> anything from authtry_bsses[] for a received DEAUTH since it is not
>> applicable.
>
> Yeah, indeed. Would not modifying authtry_bsses for a _received_ DEAUTH
> fix it?

Sure, it would.  How do I differentiate between received and
transmitted DEAUTH?  They seem to go through the same function, or
maybe I'm wrong.  Do I check the MAC in the mgmt header? :-)

> johannes
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>