Johannes Berg wrote: > On Thu, 2009-10-01 at 01:13 +0300, Jouni Malinen wrote: >> To me, this looks broken. When wpa_supplicant requests a >> disassociastion, it is _only_ asking for disassociation, not >> deauthentication. cfg80211/mac80211 may not currently handle that, but >> as far as I can tell, it sounds like an issue there and not in >> wpa_supplicant. Johannes may disagree with this, though. > > cfg80211/mac80211 _do_ handle that. If you ask for disassociation, it > stays authenticated, and later expects you to still remember that and > refuses authentication since you're already authenticated. > >> I don't think either of those options would be acceptable for >> wpa_supplicant and the correct fix is to make cfg80211/mac80211 be able >> to handle authentication to a STA that is already authenticated. If >> that is not acceptable, this hack needs to be hidden in driver_nl80211.c >> instead of polluting core wpa_supplicant code which is supposed to be >> driver independent. In other words, make driver_nl80211.c deauth if auth >> fails and then try auth again. I don't really like that much, but if >> this needs to be worked around in wpa_supplicant, that is the most >> likely place where such a change could be considered. > > I still don't see how it makes sense to authenticate while still being > authenticated. The client might have lost state info (rebooted, etc.). Let it redo the auth if it wants to, deauth if it fails. ~will~ -- 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
