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:
signature.asc
Description: This is a digitally signed message part
