On Mon, 2009-10-12 at 10:15 +0300, Jouni Malinen wrote: > Though, even in this case, there is actually a bug somewhere (in > mac80211, I would assume).. The authentication attempt with the second > AP times out because mac80211 ends up sending the direct probes to the > MAC address of the old AP (which is now turned off). When wpa_supplicant > tries to authenticate again, the direct probes are going to the correct > destination and connection can be established. I can't see that happen in mac80211 -- can somebody run this with some printks in cfg80211 that tell us what exactly is being passed down to mac80211's auth() call? > I can reproduce this with the current wpa_supplicant (that has a > workaround for this EALREADY for authentication case, but not for > assoc) and the current wireless-testing. Roaming will get mac80211 into > very odd state.. > > Not only is this association failing (after the authentication with the > same AP actually worked), but the scanning state will also get quite > confused.. The next scan trigger after this is never completed (iw scan > gets stuck). Or well, actually, once I wait long enough for the AP to > deauthenticate the client, it looks like mac80211 can recover. The scan > command returned after five minutes of waiting.. ;-) Good hint. It looks like it gets stuck between assoc and auth for the old AP? > > The "Association request to the driver failed" will > > be shown even without "-d". Also note that the association > > seems to actually work, e.g. I can ping throught the > > connection. > > mac80211 remains associated with the old AP (I think) and somehow > remains in the state between authentication and association (with the > new AP) which will block scans. I think we need a cfg80211 event tracer :) Actually, does wpa_supplicant _deauth_ from the AP, or does it just disassoc? It's definitely supposed to deauth. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
