[PATCH 1/2] Allow scanning while in authenticated only state
maximlevitsky at gmail.com
Sat Oct 31 06:33:16 EDT 2009
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 . 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 , 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
This is a workaround/hack, but at least it works....
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
@@ -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 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,
+ if (err)
+ return err;
+ return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DEAUTHENTICATE,
More information about the HostAP