wpa_supplicant over-eagerly blacklisting AP sending PREV_AUTH_NOT_VALID?

[Jason Abele]

On Tue, Feb 2, 2016 at 8:25 AM, Gareth McCaughan
<gareth.mccaughan at pobox.com> wrote:
> I have some reason to believe the following:
>
>   * Some Cisco wireless APs will regularly try to force clients
>     to reauthenticate by sending deauthorization frames
>     with reason code 2 (PREV_AUTH_NOT_VALID).
>
>   * When one of these arrives, wpa_supplicant will respond by
>     putting the AP on a blacklist and roaming to another AP
>     rather than by immediately trying to reauthenticate with
>     the same AP.
>
> This is a Bad Thing (isn't it?) because e.g. if you have two of
> these APs within range but one provides a much better signal
> than the other, you'll alternate between them rather than
> sticking with the good one. It seems like it might be better
> for wpa_supplicant to try the original AP again immediately.
>
> (The problem that actually sent me looking at this stuff is
> more severe and involves machines completely falling off
> the network after several of these transitions, but I think
> that's a separate issue that I don't understand yet.)

This is probably the APs attempting to do some form of "smart" band
steering or load balancing, I had a similar problem, especially the
falling off the network completely.

> (The machine in question is a Lenovo laptop with an Intel
> wireless card; if the details of the hardware are important
> I can find them out, but I bet they aren't. It's running
> Ubuntu 14.04 LTS which uses wpa_supplicant 2.1, but it
> looks to me as if the relevant code is the same in more
> recent versions of wpa_supplicant. Again, more details
> are available on request.)

The fix for me was a one-liner to clear the blacklist after any
successful connection:
https://w1.fi/cgit/hostap/commit/?id=a20a3616

The fix is in wpa_supplicant v2.5

Hope that helps,
Jason