[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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
