On Fri, 2008-11-21 at 17:16 +0530, Vivek Natarajan wrote: > 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? Well, the thing is that if we go to disabled state then we don't actually scan and associate again. Only if wpa supplicant is running does that happen. > > 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. Oh. You're right, we do go directly to disabled. I thought we somehow went back to 'request auth' (which is not a proper state, unfortunately) Hmm. I guess what your patch is doing is the best thing at this point then until we actually rewrite the roaming code. Can you add a comment to _set_disassoc that the "reason" variable passed is either our own reason (when self_disconnected is true) or the remote reason (when self_disconnected is false) please? Also, I haven't checked, but there may be other places where we could pass the remote reason. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
