mac80211: fail back to use associate from reassociate failure
Some APs have strict checking between associate and reassociate. In
a case when an AP is restarted during a connection, it denies the
mac80211 reassoc request since this is a new association for the AP.
To fix this problem, we need to check the status code against
WLAN_STATUS_REASSOC_NO_ASSOC and clear ifsta->prev_bssid_set in
handling the association failure response.
Signed-off-by: Zhu Yi <[email protected]>
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index b003912..dacd2d3 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1182,6 +1182,8 @@ static void ieee80211_rx_mgmt_assoc_resp(struct net_device *dev,
if (status_code != WLAN_STATUS_SUCCESS) {
printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
dev->name, status_code);
+ if (status_code == WLAN_STATUS_REASSOC_NO_ASSOC)
+ ifsta->prev_bssid_set = 0;
return;
}
-----Original Message-----
From: Zhu Yi [mailto:[email protected]]
Sent: Tuesday, May 15, 2007 12:23 PM
To: Sandesh Goel
Cc: Jouni Malinen; [email protected]; John W. Linville
Subject: RE: [PATCH] mac80211: fail back to use associate from
reassociate
On Mon, 2007-05-14 at 22:41 -0700, Sandesh Goel wrote:
> Therefore, the AP should not return the said error code
> (WLAN_STATUS_REASSOC_NO_ASSOC) unless it has checked (using some inter
> AP protocol) that no other AP in the ESS has an existing association
> with the requesting STA. If the AP is returning the error without
> doing this check, I would think that it is an AP bug.
The AP was the only one in the ESS, so it should be OK.
[Sandesh]
[Sandesh] How does the AP know that it is the only one in the ESS? It
can't surely assume that. Is it configured with this information? Did it
try to find out if there are other APs in the ESS? E.g. would it behave
differently if you setup another AP in your ESS?
> It would be interesting to know which AP behaves in this way and
> whether
> is really does the check correctly or not. Note that the AP itself
> having rebooted shouldn't cause this error code to be returned, which
> is what I found strange.
Do you mean the AP should remember all its associated STAs before it
rebooted?
[Sandesh]
[Sandesh] I didn't say that AP needs to remember that. However, it
should honor the reassoc request if it is not sure about whether the
requesting STA was associated in the ESS or not.
Thanks,
-yi
I would like to offer my 2 cents here.
While the proposed fix for this problem seems reasonable, I think the AP
behavior is definitely suspect.
It is certainly legal for a STA to send a reassoc request to an AP with
which it has no existing association as long as the STA has an existing
association with some other AP within the same ESS.
Therefore, the AP should not return the said error code
(WLAN_STATUS_REASSOC_NO_ASSOC) unless it has checked (using some inter
AP protocol) that no other AP in the ESS has an existing association
with the requesting STA. If the AP is returning the error without doing
this check, I would think that it is an AP bug.
It would be interesting to know which AP behaves in this way and whether
is really does the check correctly or not. Note that the AP itself
having rebooted shouldn't cause this error code to be returned, which is
what I found strange.
Regards,
Sandesh
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Zhu Yi
Sent: Thursday, May 10, 2007 8:51 AM
To: Jouni Malinen
Cc: [email protected]; John W. Linville
Subject: Re: [PATCH] mac80211: fail back to use associate from
reassociate
On Wed, 2007-05-09 at 08:28 -0700, Jouni Malinen wrote:
> Can you please identify such an AP? This sounds like a workaround that
> makes the non-AP STA (client) behave in a way that does not match with
> IEEE 802.11 standard and in general, I'm against this change without a
> very good reason for it.
I take it an error handling code. When an AP denies a STA reassociation
request with the reason "there is no previous association, why do you
send reassociation request to me?", this is an indication for the STA to
switch to association request and retry. Currently, mac80211 just try
reassociation over and over. The result is it can never associate with
the AP.
I don't see how it breaks the 802.11 standard. If you do, please point
it out and how are you going to fix this problem?
> This type of change would, e.g., break IEEE
> 802.11r fast transition which can only be done using reassociation.
In .11r, can AP reject reassociation request if there is no previous
association from the same STA?
Thanks,
-yi
On Wed, May 09, 2007 at 01:41:52PM +0800, Zhu Yi wrote:
> mac80211: fail back to use associate from reassociate failure
>
> Some APs have strict checking between associate and reassociate. In
> a case when an AP is restarted during a connection, it denies the
> mac80211 reassoc request since this is a new association for the AP.
> To fix this problem, we need to check the status code against
> WLAN_STATUS_REASSOC_NO_ASSOC and clear ifsta->prev_bssid_set in
> handling the association failure response.
Can you please identify such an AP? This sounds like a workaround that
makes the non-AP STA (client) behave in a way that does not match with
IEEE 802.11 standard and in general, I'm against this change without a
very good reason for it. This type of change would, e.g., break IEEE
802.11r fast transition which can only be done using reassociation.
--
Jouni Malinen PGP id EFC895FA
On Thu, May 10, 2007 at 11:20:50AM +0800, Zhu Yi wrote:
> I take it an error handling code. When an AP denies a STA reassociation
> request with the reason "there is no previous association, why do you
> send reassociation request to me?", this is an indication for the STA to
> switch to association request and retry. Currently, mac80211 just try
> reassociation over and over. The result is it can never associate with
> the AP.
OK. This sounds reasonable. I went through the IEEE 802.11 standard and
it does not seem to describe this part of re-association process in any
level of detail apart from allocation a status code for reporting
failures to validate association status.
> In .11r, can AP reject reassociation request if there is no previous
> association from the same STA?
.11r does not use this status code. I was concerned about this in
general, i.e., anything that converts re-association to association
sounds somewhat undesired, but it looks like this particular status code
could be the only exception for this. I still don't see how the AP in
this case would have known about the association status for the full ESS
(since I don't see how it would know that it is the only AP in the ESS).
Anyway, non-AP STA does not have enough context to determine what
exactly happen, so it cannot really do much more than either stop trying
to re-associate or try to associate what is what your change is
proposing ot do.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2007-05-09 at 08:28 -0700, Jouni Malinen wrote:
> Can you please identify such an AP? This sounds like a workaround that
> makes the non-AP STA (client) behave in a way that does not match with
> IEEE 802.11 standard and in general, I'm against this change without a
> very good reason for it.
I take it an error handling code. When an AP denies a STA reassociation
request with the reason "there is no previous association, why do you
send reassociation request to me?", this is an indication for the STA to
switch to association request and retry. Currently, mac80211 just try
reassociation over and over. The result is it can never associate with
the AP.
I don't see how it breaks the 802.11 standard. If you do, please point
it out and how are you going to fix this problem?
> This type of change would, e.g., break IEEE
> 802.11r fast transition which can only be done using reassociation.
In .11r, can AP reject reassociation request if there is no previous
association from the same STA?
Thanks,
-yi
On Mon, 2007-05-14 at 22:41 -0700, Sandesh Goel wrote:
> Therefore, the AP should not return the said error code
> (WLAN_STATUS_REASSOC_NO_ASSOC) unless it has checked (using some inter
> AP protocol) that no other AP in the ESS has an existing association
> with the requesting STA. If the AP is returning the error without
> doing this check, I would think that it is an AP bug.
The AP was the only one in the ESS, so it should be OK.
> It would be interesting to know which AP behaves in this way and
> whether
> is really does the check correctly or not. Note that the AP itself
> having rebooted shouldn't cause this error code to be returned, which
> is what I found strange.
Do you mean the AP should remember all its associated STAs before it
rebooted?
Thanks,
-yi