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

[Maxim Levitsky]

On Sat, 2009-10-31 at 11:02 +0100, Johannes Berg wrote: 
> 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.
Exactly, at least for now.

How about putting this in wpa_supplicant, and end all trouble with this
for once?

This is a workaround/hack, but at least it works....

Best regards,
Maxim Levitsky

---


commit e57bfd6e760c32177ab74c462839dd20a92343b8
Author: Maxim Levitsky <maximlevitsky at gmail.com>
Date:   Sat Oct 31 12:05:35 2009 +0200

    driver_nl80211: send deauth on disassoc

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index b3861f5..dfed87d 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -2046,12 +2046,18 @@ static int wpa_driver_nl80211_deauthenticate(void *priv, const u8 *addr,
 static int wpa_driver_nl80211_disassociate(void *priv, const u8 *addr,
                                           int reason_code)
 {
+       int err;
        struct wpa_driver_nl80211_data *drv = priv;
        if (!(drv->capa.flags & WPA_DRIVER_FLAGS_SME))
                return wpa_driver_nl80211_disconnect(drv, addr, reason_code);
        wpa_printf(MSG_DEBUG, "%s", __func__);
        drv->associated = 0;
-       return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
+
+       err = wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
+                                      reason_code);
+       if (err)
+               return err;
+       return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DEAUTHENTICATE,
                                       reason_code);
 }