[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?
johannes
On Wed, 2011-06-08 at 04:48 -0700, Paul Stewart wrote:
> >> 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? :-)
I think you have to check the address, yeah.
johannes
On Wed, Jun 8, 2011 at 4:44 AM, Johannes Berg <[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Downsteram DEAUTH messages do not refer to a current authentication
attempt -- AUTH responses do. Therefore we should not allow DEAUTH
from an AP to void state for an AUTH attempt in progress.
Signed-off-by: Paul Stewart <[email protected]>
---
net/wireless/mlme.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 493b939..3633ab6 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -170,7 +170,9 @@ void __cfg80211_send_deauth(struct net_device *dev,
break;
}
if (wdev->authtry_bsses[i] &&
- memcmp(wdev->authtry_bsses[i]->pub.bssid, bssid, ETH_ALEN) == 0) {
+ memcmp(wdev->authtry_bsses[i]->pub.bssid, bssid,
+ ETH_ALEN) == 0 &&
+ memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) == 0) {
cfg80211_unhold_bss(wdev->authtry_bsses[i]);
cfg80211_put_bss(&wdev->authtry_bsses[i]->pub);
wdev->authtry_bsses[i] = NULL;
--
1.7.3.1
On Wed, 2011-06-08 at 05:52 -0700, Paul Stewart wrote:
> Downsteram DEAUTH messages do not refer to a current authentication
> attempt -- AUTH responses do. Therefore we should not allow DEAUTH
> from an AP to void state for an AUTH attempt in progress.
Could you reproduce the original problem? This looks nice.
> Signed-off-by: Paul Stewart <[email protected]>
> ---
> net/wireless/mlme.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 493b939..3633ab6 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -170,7 +170,9 @@ void __cfg80211_send_deauth(struct net_device *dev,
> break;
> }
> if (wdev->authtry_bsses[i] &&
> - memcmp(wdev->authtry_bsses[i]->pub.bssid, bssid, ETH_ALEN) == 0) {
> + memcmp(wdev->authtry_bsses[i]->pub.bssid, bssid,
> + ETH_ALEN) == 0 &&
> + memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) == 0) {
> cfg80211_unhold_bss(wdev->authtry_bsses[i]);
> cfg80211_put_bss(&wdev->authtry_bsses[i]->pub);
> wdev->authtry_bsses[i] = NULL;