On Sat, 2009-10-31 at 11:46 +0200, Maxim Levitsky wrote: > > I think you just need this wpa_supplicant patch: > > http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch > > Nope, this patch doesn't help. > > if I remove the bssid_changed, then it seems to work when connecting to > same AP, but still scan hangs when connecting to different. Hmm, Luis said it worked when connecting to a different AP. But he got assoc refused and/or disassoc from the AP > The problem is that wpa_supplicant doesn't do deauthentication > explicitly, and I was told that this is right thing to do. This confuses > all the nl80211 and mac80211... I thought Jouni committed that workaround. I'm still not convinced that wpa_supplicant is doing the right thing. > I also think that its best just to do both deauthentication and > disassociation in same time. But then why do we bother? > Yet, I think this path is ok, that is, when you disallow scanning, you > can be sure that wifi will be dead, and this patch catches the situation > when it for sure will disallowed forever. True, in some sense, but the real problem is that the authentication is lingering along. If we really need to clean that up in the kernel then we'd have to time out authentication structs that didn't get promoted to association, instead of just ignoring them like your two patches implement [1]. However, since we put control of all this into wpa_supplicant, I don't know whether the kernel really should be required to clean up -- I was going to write "clean up after it" but that's not true [2], you're proposing that the kernel clean up *while* wpa_supplicant is in control. I don't think that's right, since it might actually want to hang on for an authentication while doing something else, for a while at least. How can we calculate an upper bound on that in the kernel? Now, I can kinda agree that we should allow authentication frames to go through while already authenticated, but that's something quite different although your patches here would also allow that in some hackish way (by accumulating more and more authentication structs that are then ignored). Now, especially since you say that this still runs into problems while connecting to a new AP, I think that wpa_supplicant should deauthenticate from the old AP. After all, it wants to eventually control FT and anything we do in the kernel will come back and interfere with that. johannes [1] and that'd have to be in cfg80211 [2] Except when the interface is taken down, but that is already cleaned up by cfg80211.
Attachment:
signature.asc
Description: This is a digitally signed message part
