On Fri, 2009-10-02 at 23:31 +0200, Trepak Vilmos wrote: > 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. In case you haven't noticed, we're talking about the client (wpa_supplicant) :) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
