On Wed, 2024-08-28 at 10:49 +0300, Jouni Malinen wrote: > On Wed, Aug 28, 2024 at 09:19:05AM +0200, Johannes Berg wrote: > > On Tue, 2024-08-27 at 15:09 -0400, Alan Stern wrote: > > > Well, I'd prefer to avoid unnecessary roaming because of the short > > > interruptions in service that it causes. > > > > Right, but the interruptions for you are much longer because it _fails_. > > Perhaps wpa_supplicant should remember that, and not attempt to use FT > > when it keeps failing. > > That depends on what exactly is failing.. Agree. > I did not bother going through > all the details of the debug log since it seemed to be missing > something. Also seems that way, yes, though not sure why. But for example: > wpa_supplicant[5906]: wlan0: FT: RSNE mismatch between Beacon/ProbeResp and FT protocol Reassociation Response frame is something that perhaps could result in an FT-blocklist or something for the BSSID in question, or perhaps even the whole network since it's likely to be a single controller/unified installation or so. > I did notice one of the APs using comeback mechanism which is > a sign of the STA having an older entry on it and PMF being used. That > is actually not a failure but part of the expected behavior for > protecting against disconnection attacks. One would need to have a full > log from the first initial connection to the point of a failed > reassociation. True. > Ideally, I'd like to see that from wpa_supplicant stdout > with -ddt on the command line instead of syslog. Right ... That needs more arguments to integrate with NetworkManager (or configuration to have at least dbus), but I'm not sure how exactly that'd work and how you'd stop the system one. Actually if it's with systemd then that/journal will log everything from the stdout/stderr, just not necessarily in the syslog - so perhaps adding -t in addition to -dd and then using journalctl -u wpa_supplicant would work. johannes
