On Fri, Jul 01, 2016 at 10:36:37AM +0200, Mikael Kanstrup wrote: > On Android M we've seen cases where Android's way of roaming > sometimes end up blacklisting incorrect bss. > > Connected to BSSID1 to roam to another AP the following sequence of > commands are used: > SET_NETWORK 0 bssid <BSSID2> > ENABLE_NETWORK 0 > REASSOCIATE > > Most of the time this works just fine, though if authentication > timer times out (probably due to auth/assoc/eapol packet loss) the > BSSID roamed away from gets blacklisted (BSSID1), not the one > failing to reassociate with (BSSID2). Hmm.. Is that really the case for lost EAPOL frames? That would be post-association and wpa_s->bssid is set to the new BSSID when completing association. The auth/assoc case sounds more likely to be an issue, though. > Question is, is this way of using the REASSOCIATE command to perform > roam operation valid? Yes, even if not really the most optimized way of doing that. > I worked on a patch that solved this specific case but had to apply > some hacks to reproduce it with hwsim tests. It would be great with > some feedback on the scenario and attached patches. I think not all > of them should really be applied but should help discussing the > problem seen. The testing patches 1-4 would need some cleanup to be acceptable, e.g., by making the wpa_s->ignore_auth_resp behavior protected with #ifdef CONFIG_TESTING_OPTIONS. In addition, I'm not sure why 2/5 is needed since the driver parameter is parsed with strstr searches of substrings from the full parameter string. Instead of adding IGNORE_AUTH_RESP, I'd use the existing SET control interface command. And the new test case would need to reset IGNORE_AUTH_RESP in all error cases (e.g., try .. finally) or make FLUSH clear this in wpa_supplicant_ctrl_iface_flush(). As far as the actual fix patch 5/5 is concerned, I don't think I like the use of wpa_s->pending_bssid to override wpa_s->bssid in wpa_supplicant_timeout() since this function can be called during EAPOL timeout (i.e., that post-association case mentioned above). While this may work now for most cases, this does not sound like the correct thing to do. It might be fine to do so in wpa_state == WPA_AUTHENTICATING/ASSOCIATING just like the wpa_supplicant_deauthenticate() does. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
