802.11r (FT) and WPA3 SAE

Hello all,

is there by now actually a workaround for 802.11r Fast Transition in combination with WPA3 SAE?
All threads I have found on the subject are already orphaned.

I could see that under OpenWRT 22.03.x 23.05.rc2 FT in combination with WPA3 SAE is not possible, but PSK2+CCMP works fine.


I'm slightly confused about your post, excuse me to ask but how did you verify this with testing?

On my Mochabin I run a MT7915e on Openwrt 23.05.1 and on my gl-inet Flint 22.02.x.

But both seem to use roaming aslong I have the mobility domain set.

When I kick client X it always falls back to the flint one or vice versa to the Mochabin when the kick happened on the Flint, and both use SAE.

I'm just wondering why it would not work in your case?, Or is my way of testing inaccurate?

I do note over time clients either get stuck on a endpoint it has the best connection to, but sometimes one endpoint is stronger than the other and then it only works like my example more as a fallback.

WPA2-EAP, WPA3-EAP and WPA3-SAE work in a similar way in regard to FT: the authentication process whether 802.1x or SAE completes and only then is PMK generated. This is in contrast to WPA2-PSK where PMK is calculated directly from SSID and PSK. It means that you can't use "Generate PMK locally" as the APs don't know it.

But, why it doesn't work for you with 22.03+, I'm not sure, it should automatically set up R0KH and R1KH

thank you for the answer.
So I can only describe what I have found myself and that is now the following.
I've been debugging my mesh network for a long time, tried various parameters, finally returned to the default settings from the OpenWRT wiki and wondered what else I can do.
Then I noticed that the only thing that is still different is the closure tunnel standard.
Changed it from sae to psk2+ccmp and voila, problem solved.

Then I read on the net about WPA3 and 802.11r and read about problems and the recommendation to switch to WPA2.

Do you set option ft_psk_generate_local to 0 and do you set r0kh and r1kh manually?
That's somethink i've never tried.

this is what I have in my wireless configuration:

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'wlan0'
	option mode 'ap'
	option ssid 'Mochabin-5G'
	option encryption 'sae'
	option key '<private>'
	option ieee80211r '1'
	option mobility_domain '27F3'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option ieee80211k '1'
	option bss_transition '1'

basicly mobility domain is all the same over all access points.

note that for roaming I tried to keep the sae password the same and the ssid also the same I made pretty much almost the same configuration on the other AP, except for channel that way they don't overlap and I can check it with wifiman app on android I think if something is different roaming might fail.

Like I said, SAE (and EAP) cannot work with ft_psk_generate_local as PMK is known only to the AP you connected to first.

You have to turn off psk_generate_local. I also had trouble with some devices if "Disconnect on low ACK" was enabled, so you can try turning that off too.

In theory you would have to set up R0KH and R1KH - I always set it manually. But in the documentation it says that openwrt will do it for you. The easiest way to manually set it up is to:

  • create a shared secret key (that can be any random 256 bits):
    • you can use an online utility such as this one or
    • generate it yourself using a command such as: dd if=/dev/random bs=16 count=1 2>/dev/null | md5sum | awk '{print $1}' on the router itself
  • set r0kh to: ff:ff:ff:ff:ff:ff * your_key_here (in /etc/config/wireless put commas instead of spaces)
  • set r1kh to: 00:00:00:00:00:00 00:00:00:00:00:00 your_key_here (in /etc/config/wireless put commas instead of spaces)

The above will enable hostapd's automatic FT RRB message exchange so you don't need to list all APs everywhere.


Ah, could it be device specific ?

On my phone it works which is a Android 12 device, I readed somewhere that some devices like Apple can have issues with 802.11r?

From what I could find there are some options which might cause issues to such devices:

option ft_over_ds '1' this should be to 0 which should indicate to be over air.

krack protection needs to be set off, and maybe also 802.11w (managed frame protection).

Could you check if it makes a change?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.