Re: [PATCH 1/2] Allow scanning while in authenticated only state

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]