WiFi constantly changes association

[Jouni Malinen]

On Wed, Aug 28, 2024 at 02:02:32PM -0400, Alan Stern wrote:
> Attached is a compressed file containing a 10-minute section of the 
> journalctl output.  wpa_supplicant was running with -ddt and without -s, 
> so this should contain all of its output.
> 
> Initially both wpa_supplicant and NetworkManager were turned off.  The 
> log starts at the time when I turned on wpa_supplicant, and a few 
> seconds later, turned on NetworkManager.  An INVALID_IE event occurred 
> at timestamp 12:03:59.  The output is so voluminous it's hard to see 
> what's really happening, however.

Thanks. This seems to make it clear that the AP has an issue in its FT
implementation at least in the BSS that operates on the 6 GHz band.
Based on the OUI, that AP is from HPE (Aruba?), so I guess I'll check
with them whether this is a known issue.

The log did not include any other attempt to use the FT protocol, so I
could not check whether it could have worked on other bands. However, I
do note that the RSNE from the 5 GHz band is indeed different and
matches the value that the AP included on the 6 GHz band in the
Reassociation Response frame, so this seems to point towards some
implementation or configuration issues on the AP side and that could
result in an issue that is specific to the 6 GHz band.

PS.

The reason for this particular sequence is in the STA first connecting
on the 5 GHz band and wpa_supplicant being configured to use bgscan
to find a better candidate. Background scan from that ends up finding a
6 GHz AP and that has better estimated throughput and wpa_supplicant
decides to roam based on that. Since FT is enabled here, that roam tries
to use FT from the 5 GHz AP to the 6 GHz one and that fails. This
results in the 6 GHz AP getting temporarily disabled and a 5 GHz AP
being selected as the next option. That succeeds with initial FT
mobility domain association (i.e., not using FT protocol). However, now
we get back to that same state where bgscan will find a better AP on 6
GHz and that will result in the same failure..

As far as I can tell, the main issue here is in AP misbehavior. This
could be worked around by disabling FT or bgscan. A potential
wpa_supplicant change could be considered to disable FT protocol for
that specific AP when this type of behavior is detected. I'll talk to
Aruba first to see if I can get a better understanding on what is behind
this AP behavior.

-- 
Jouni Malinen                                            PGP id EFC895FA