Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >> * 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. > we block scans for a short time while trying to probe/associate and > wpa supplicant request one exactly then. > However, I still think going to disabled is wrong. We should be in a > different state If the AP has explicitly told us that it is leaving the bss, what is the point in retrying in associate state? DISABLED state would be ideal for fresh scanning & assocation. What do you think? > 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? > 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. If AP loses power, probe request times out and we directly move to disabled state. Hence we don't spend time in ASSOCIATE/DIRECT-PROBE state. The same behaviour is expected when we receive a disassoc frame with reason code as "AP leaving BSS". There should not be any intermediate state like ASSOCIATE. Thanks for your time, Vivek. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
