Re: [PATCH] mac80211: Look out for some other AP when disassoc is received.

[Johannes Berg <johannes@sipsolutions.net>]

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

On Wed, 2008-11-19 at 18:03 +0530, Vivek Natarajan wrote:

> Here is the test scenario that exposed this issue:
> * There are two APs with the same SSID so that the sta can roam if one is down.
> * When the AP to which the station is connected is brought down or restarted,
>   it sends( should send according to 802.11 spec) a disassoc frame with a
>   reason code of 8 which means the sender is leaving the BSS.
> * After receiving a disassoc, mac80211 moves to ASSOCIATE state in which scanning
>    is disabled. So, for the first scan request from wpa_supplicant(scan duration of 30sec),
>    it tries to send probe   request to the same AP instead of scanning for other APs.
>    Then it moves to DISABLED  state since there will be no probe response.
> * The next scan request comes only after 30sec and now it will scan for all available APs
>    since scanning  is supported in DISABLED state.
>     So, it takes atleast 30sec to connect to some other AP.

Ok, I understand the scenario, I think. But I don't understand why going
to DISABLED fixes this. In DISABLED the mlme does nothing at all, I
think, so how can that fix it?

We can only request a new scan if we get into ieee80211_sta_config_auth,
which we can only get into by setting IEEE80211_STA_REQ_AUTH, which in
turn we get from ieee80211_sta_req_auth. Therefore, going into disabled
won't help at all.

Ok, I think I see, let me take a step back: you're not just using the
mlme code in the kernel but wpa supplicant as well? That has a 30 second
scan timeout? Seems a bit of a race condition thing, we block scans for
a short time while trying to probe/associate and wpa supplicant requests
one exactly then.

However, I still think going to disabled is wrong. We should be in a
different state and if we detect a problem with the AP, got disconnected
and it didn't respond to probes, then we could go back to scanning if we
had previously been associated. Not if we haven't ever been associated
though because then we could get caught in an endless loop.

I think you've also not accounted for the possibility that the AP simply
lost power for some reason and didn't send a deauth frame at all.

Unfortunately, I don't see a good way to fix this. I've long meant to
completely rewrite the MLME state machine which would have made this
easier, never got around to it though. Taking into account what I've
just said, do you have another idea?

> > Also, the reason code that's being passed is the one we send ourselves,
> > not the one we received.
> 
> I have passed the reason code from ieee80211_rx_mgmt_disassoc which is called
> only after we receive a disassoc frame from the AP.

Yes, but the parameter we pass to that function used to be for the
reason code we send, I have no trouble making it both depending on the
other parameters though, but I guess we should document that if we
really need to do it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]