Re: WiFi constantly changes association

[Jouni Malinen <j@w1.fi>]

On Wed, Aug 28, 2024 at 09:55:09AM +0200, Johannes Berg wrote:
> 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.

Somehow I managed to miss then entry.. This is something that I'd be
quite interested in getting more details for since this seems to show a
clear interoperability issue with the FT reassociation implementation
between the AP and the STA.. I'd like to see the full wpa_supplicant
debug sequence that started from selecting the AP and how it resulted in
this mismatch.

Is there any idea which AP devices are used in the network? It is
clearly misbehaving if the wpa_supplicant debug log entries are accurate
on what RSNE values it uses:

RSNE in Beacon/ProbeResp - hexdump(len=32): 30 1e 01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 05 00 0f ac 03 e8 00 00 00 00 0f ac 06
RSNE in FT protocol Reassociation Response frame - hexdump(len=44): 30 2a 01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 01 00 0f ac 03 e8 00 01 00 ff 84 62 84 5a a3 06 82 4f b4 2d 43 36 76 87 4b

It is expected to add the PMKID entry for FT, but the AP changed its
list of AKM suites (!?) and removed the group management cipher suite.
Such changes are not allowed and the STA has to stop since those would
be a clear indication of an active downgrade attack. While
wpa_supplicant could in theory prevent FT attempts with this AP for some
time from the view point of interoperability workarounds, I'm not
exactly happy about such a change since it could make it easier to
perform various attacks.

As far as the AKM suite lists are concerned, the RSNE from scan results
indicated 00-0F-AC:5 (802.1X with SHA-256) and 00-0F-AC:3 (FT with
802.1X) while the RSNE from Reassocation Response frame indicated
00-0F-AC:1 (802.1X with SHA-1) and 00-0F-AC:3 (FT with 802.1X). This
feels really strange. Either the AP has a really broken FT
implementation or something has messed up with scan results.. Since this
attempt is on the 6 GHz band, I'm assuming the AP has other BSSs on the
2.4 and 5 GHz bands and it might be possible that there are differences
in which AKMs are enabled on different bands. That would be a bit
strange configuration of the AP, but still, possible. It would be nice
to get full scan results that show the RSNE values from all bands.

-- 
Jouni Malinen                                            PGP id EFC895FA