On Tue, Feb 2, 2016 at 8:25 AM, Gareth McCaughan <gareth.mccaughan@xxxxxxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
