Roaming on android blacklists incorrect bss

[Jouni Malinen]

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