802.11r Fast Transition how to understand that FT works?

[Lynx]

FT with WPA3-SAE has been working well since I implemented the advice from your post here:

802.11r Fast Transition how to understand that FT works?

I have not even tried to measure any difference between them. If you wish to try WPA3-SAE on your own, I'll give you some clues. The minimum config you need is to enable 802.11r, and make sure to DISABLE Generate PMK locally (ft_psk_generate_local). This option is currently not working with WPA3. OpenWRT will provide default values for the keys and identifiers, so there's no need to set them: nas_identifier is taken from the BSSID; mobility_domain will be the first 4 hex digits of the md5sum…

By the way all, is:

        option reassociation_deadline '20000'

still recommended? Presumably that's the only extra setting that might be warranted.

[McGiverGim]

With the latest master, it works too for sae-mixed, without needing to configure keys or similar. I was waiting for the fix a lot of time!

[cotequeiroz]

@Lynx

By the way all, is:

        option reassociation_deadline '20000'

still recommended? Presumably that's the only extra setting that might be warranted.

TLDR: I don't know if really helps.

This has always been debatable. I first learned it as advice to Apple device owners, IIRC, from some Cisco recommendation or a default value of theirs.

I add it to my routers because I have Apple devices around, and I haven't heard of it interfering with anything. However, I can't really pinpoint any measurable improvement that would justify changing the OpenWrt default.

I moved from SAE to 802.1x, and Apple devices still give me some trouble, often showing no Wi-Fi icon, while successfully pinging the router, regardless of the setting. This is the opposite of what I had with SAE-FT: Wi-Fi icon, but no connectivity. At least now, it returns to normal without having to turn the Wi-Fi off and on again.

I noticed that Apple devices roam a lot more than Windows or Android, so they may stress the APs more than other devices. Here are some numbers from 9 APs showing STAs with more than 100 FT authentications over a period of 1 week. There are a couple of Android devices in the mix, but none reach the century mark. 5c:cd is a Windows notebook that stays in an area with poor signal coming from 5 different APs, so it roams a lot without moving; the rest are all iPhones and Apple Watches. The watches don't roam nearly as much as the iPhones. I think it is because they stick to 2.4G more than the phones--here 2e:37... and 8a:6b... are an iPhone/Apple Watch pair that should be close together most of the time:

$ sed -n -e '/EAPOL-4WAY-HS-COMPLETED\|start 4-way\|CTRL-EVENT-EAP-SUCCESS\|skip.*EAP/{s/.*STA //;s/.*\(EAPOL-4WAY-HS-COMPLETED\|CTRL-EVENT-EAP-SUCCESS2\) \(.*\)$/\2 \1/;s/\(..:..\):..:..:..:\(..\)/\1:xx:xx:xx:\2/;p}' hostapd.log-20240225 | sort | uniq -c | grep -B3 '^....[0-9].*4-way'
    102 0e:8c:xx:xx:xx:5a CTRL-EVENT-EAP-SUCCESS2
     97 0e:8c:xx:xx:xx:5a EAPOL-4WAY-HS-COMPLETED
    939 0e:8c:xx:xx:xx:5a IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
    939 0e:8c:xx:xx:xx:5a WPA: FT authentication already completed - do not start 4-way handshake
--
   1418 2e:37:xx:xx:xx:cf CTRL-EVENT-EAP-SUCCESS2
   1197 2e:37:xx:xx:xx:cf EAPOL-4WAY-HS-COMPLETED
  11348 2e:37:xx:xx:xx:cf IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
  11336 2e:37:xx:xx:xx:cf WPA: FT authentication already completed - do not start 4-way handshake
--
    548 32:1d:xx:xx:xx:a3 CTRL-EVENT-EAP-SUCCESS2
    471 32:1d:xx:xx:xx:a3 EAPOL-4WAY-HS-COMPLETED
   5632 32:1d:xx:xx:xx:a3 IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
   5630 32:1d:xx:xx:xx:a3 WPA: FT authentication already completed - do not start 4-way handshake
--
    999 56:b0:xx:xx:xx:6b CTRL-EVENT-EAP-SUCCESS2
    888 56:b0:xx:xx:xx:6b EAPOL-4WAY-HS-COMPLETED
   5075 56:b0:xx:xx:xx:6b IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
   5071 56:b0:xx:xx:xx:6b WPA: FT authentication already completed - do not start 4-way handshake
--
     98 5c:cd:xx:xx:xx:3a CTRL-EVENT-EAP-SUCCESS2
     23 5c:cd:xx:xx:xx:3a EAPOL-4WAY-HS-COMPLETED
    197 5c:cd:xx:xx:xx:3a IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
    197 5c:cd:xx:xx:xx:3a WPA: FT authentication already completed - do not start 4-way handshake
--
    901 62:96:xx:xx:xx:11 CTRL-EVENT-EAP-SUCCESS2
    788 62:96:xx:xx:xx:11 EAPOL-4WAY-HS-COMPLETED
  11225 62:96:xx:xx:xx:11 IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
  11217 62:96:xx:xx:xx:11 WPA: FT authentication already completed - do not start 4-way handshake
--
    135 8a:6b:xx:xx:xx:4f CTRL-EVENT-EAP-SUCCESS2
    134 8a:6b:xx:xx:xx:4f EAPOL-4WAY-HS-COMPLETED
   1223 8a:6b:xx:xx:xx:4f IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
   1222 8a:6b:xx:xx:xx:4f WPA: FT authentication already completed - do not start 4-way handshake
--
    735 da:5f:xx:xx:xx:fe CTRL-EVENT-EAP-SUCCESS2
    650 da:5f:xx:xx:xx:fe EAPOL-4WAY-HS-COMPLETED
   3337 da:5f:xx:xx:xx:fe IEEE 802.1X: PMK from FT - skip IEEE 802.1X/EAP
   3337 da:5f:xx:xx:xx:fe WPA: FT authentication already completed - do not start 4-way handshake

[ziddey]

Sorry for the necro, but this seems like the most appropriate thread still.

Tested a Pixel7 and 802.11r with mixed wpa2/wpa3 by just disabling "Generate PMK locally" and got:

FT: Missing required pairwise in pull response
WPA: pairwise key handshake completed (RSN)

Then additionally set Reassociation Deadline to 20000, switched to FT over DS, and enabled PMK R1 Push, and it appears to be working now:

nl80211: kernel reports: key addition failed
IEEE 802.11: associated (aid 5)
AP-STA-CONNECTED auth_alg=ft

I'm assuming it was the FT over DS that did it, but the other settings seem sound to keep regardless. Will need to test how other devices behave, but this is more or less the only one that would be roaming.

Am noticing that the previous AP doesn't disassociate until about 5.5min after for timer DEAUTH/REMOVE (station inactivity limit at default 300s/6m, disassociate on low ack enabled).

Sounds like the best move is probably to just stick with wpa2 only for now.

edit: just saw for pmk r1 push: Warning: If WPA3 (SAE) is enabled, setting this will break fast BSS transition (802.11r).

Either way, I downgraded to wpa2-psk, switched on generate pmk locally, and put things back to defaults (ft ota) except reasso deadline at 20k for a textbook implementation. Seems to be working well.

Should disasso on low ack be disabled?

Not sure why the recommended ft ota + disable generate - r1 push local didn't work when I was doing wpa2+wpa3

[EricHughes]

So your /etc/config/wireless looks like this: ?

config wifi-iface 'wifinetx'
        option device 'radiox'
        option mode 'ap'
        option network 'lan'
        option ssid 'openwrt'
        option encryption 'sae'
        option key 'xxx'
        option dtim_period '3'
        option ieee80211r '1'
        option reassociation_deadline '20000'
        option pmk_r1_push '1'
        option ft_over_ds '1'
        option ft_psk_generate_local '0'

Is there something else to consider?

[patrakov]

Yes. The level of strictness that the client enforces when roaming.

I was not able to get Arch Linux to roam. It worked in the past, but since August, it complains about some invalid information element:

Aug 05 13:46:44 dell-laptop wpa_supplicant[864]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=1080600
Aug 05 13:46:48 dell-laptop wpa_supplicant[864]: wlp2s0: SME: Trying to authenticate with 36:98:b5:19:b6:19 (SSID='ENT' freq=5500 MHz)
Aug 05 13:46:48 dell-laptop systemd-networkd[643]: wlp2s0: Lost carrier
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: disconnect from AP e2:9f:80:d4:9e:c6 for new auth to 36:98:b5:19:b6:19
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: authenticate with 36:98:b5:19:b6:19 (local address=10:51:07:8e:75:60)
Aug 05 13:46:48 dell-laptop NetworkManager[854]: <info>  [1722836808.5436] device (wlp2s0): supplicant interface state: completed -> authenticating
Aug 05 13:46:48 dell-laptop NetworkManager[854]: <info>  [1722836808.5437] device (p2p-dev-wlp2s0): supplicant management interface state: completed -> authenticating
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: send auth to 36:98:b5:19:b6:19 (try 1/3)
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: send auth to 36:98:b5:19:b6:19 (try 2/3)
Aug 05 13:46:48 dell-laptop wpa_supplicant[864]: nl80211: kernel reports: key not allowed
Aug 05 13:46:48 dell-laptop wpa_supplicant[864]: FT: Failed to set PTK to the driver
Aug 05 13:46:48 dell-laptop wpa_supplicant[864]: wlp2s0: Trying to associate with 36:98:b5:19:b6:19 (SSID='ENT' freq=5500 MHz)
Aug 05 13:46:48 dell-laptop NetworkManager[854]: <info>  [1722836808.6816] device (wlp2s0): supplicant interface state: authenticating -> associating
Aug 05 13:46:48 dell-laptop NetworkManager[854]: <info>  [1722836808.6817] device (p2p-dev-wlp2s0): supplicant management interface state: authenticating -> associating
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: authenticated
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: associate with 36:98:b5:19:b6:19 (try 1/3)
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: RX ReassocResp from 36:98:b5:19:b6:19 (capab=0x1111 status=0 aid=1)
Aug 05 13:46:48 dell-laptop systemd-networkd[643]: wlp2s0: Connected WiFi access point: ENT (36:98:b5:19:b6:19)
Aug 05 13:46:48 dell-laptop wpa_supplicant[864]: FT: FTE indicated that AP uses RSNXE, but RSNXE was not included in Beacon/Probe Response frames
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: associated
Aug 05 13:46:48 dell-laptop kernel: wlp2s0: deauthenticating from 36:98:b5:19:b6:19 by local choice (Reason: 13=INVALID_IE)

This log clearly blames the AP for not including the allegedly required RSNXE thingy, and I don't even know what it means.

EDIT: the commit that adds this message is 4 years old, so I don't know why it worked before or how to add this information element.

I have kept FT disabled since then. EDIT: found a workaround, see WPA3-Enterprise with FT needs fixing

Note: this is WPA3-enterprise, not SAE, because of a stupid mobile banking app that claims that WPA3-SAE is not secure.