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
