802.11r Fast Transition how to understand that FT works?

I'm quite sure that iOS does support 802.11r. See below for an hypothesis:

I have a suspicion that the FT problems described here can be traced to this behavior described in mac80211:

		 * The ASSOC test makes sure the driver is ready to
		 * receive the key. When wpa_supplicant has roamed
		 * using FT, it attempts to set the key before
		 * association has completed, this rejects that attempt
		 * so it will set the key again after association.
		 *
		 * TODO: accept the key if we have a station entry and
		 *       add it to the device after the station.

The rejection shows up as:

hostapd: nl80211: kernel reports: key addition failed

The TODO reminder implies that it is not really ideal. Apple devices may not like that while others will play along better.

I assume someone will have to retry to set the key. Hopefully, it won't be the STA. I wonder how much can this slow down "fast transition"? :thinking:

3 Likes

I checked my logs and see a fair number of the 'key addition failed' messages - roaming still seems to work OK for Android, but for iOS I had to move it off roaming as it was getting stuck too many times ( had to turn Wifi off-on on the iOS device to make it go).

I used to run dd-wrt, but have not followed that for a while - since they use vendor blobs for many of the drivers I wonder if their support for 802.11r is better or worse compared to Openwrt.

1 Like

I am in exactly the same boat. Android works perfectly, but my wife complains her iPhone and iPad have connection issues and she has to manually reconnect.

Is the only solution to completely disable 802.11r?

@hnyman you managed to get FT to work for many with your suggested settings:

Any thoughts on this key addition failed / iPhone issue? And what we might do to address?

@dsouza I've been reading your excellent posts on this issue. What's the latest? Must we disable 802.11r for iPhones?

Not really. I have no Apple devices to test with.

Somebody with affected devices should debug more closely than "it does not work". Probably add debug statements to the hostapd and mac80211 code, check hostapd mailing lists for relevant discussions etc.

Like cotequeiroz speculates above, it may be a combination of simplification in mac80211 and "smartness" in iOS.








This is one of 3 access points
Iphones work fine with FT

Wow that looks complicated. What's the motivation for filling in all these fields about keys?

Any idea what is the minimum one that makes iPhone work? @hnyman would you be able to hazard a guess?

Some guesses:

  • The r0 R1 keys are calculated automatically by default, likely not important.
  • Various timings, inactivity etc. might be the important ones...
  • (Mobility domain might need to be byte-symmetrical so that implementation in little-endian/big-endian routers. But as your other clients work, I guess that is not the case here.)
  • Wpa2/3 mixed mode and/or 802.11w might be problematic. So keep wpa2 and stick to w disabled.

And naturally it might be good to figure out if it is about certain iOS versions.

2 Likes

What is bite simetrical ? Like what ?

1111 -> 1111
1110 -> 0111

Is 1111 in hex definitely symmetrical though?

@hnyman thank you so much for sharing your thoughts here. Working on this now.

1 Like

Two identical bytes, like 1111 or 1313.

There has been discussion that there are differences in hostapd implementations if that is handled as byte string or as hex number.

Various CPUs may store hex number 12345678 either as 12:34:56:78 or as 78:56:34:12

See discussion starting at

I tested further without changing anything and I believe my wife's iPhone is actually fast transitioning OK. The complaint has been that now and then she has to manually reconnect to WiFi to get internet connectivity. So now I don't know what the issue is. I enabled logging and see this, which I guess confirms fast transition is working, right(?):

Tue Dec 28 19:12:16 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan1'
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK (FT)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx MLME: MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, FT)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: association OK (aid 1)
Tue Dec 28 19:12:16 2021 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx MLME: MLME-REASSOCIATE.indication(xx:xx:xx:xx:xx:xx)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan1'
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: event 6 notification
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan0: Prune association for xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: FT authentication already completed - do not start 4-way handshake

Anything else I should do?

What do you mean manually ?
Yes do not start 4-way handshake means FT

I mean hit the WiFi icon and hit it again to force reconnect. But I've never seen this myself and perhaps my wife is giving a misleading picture. Wives do that.

1 Like

Apple devices seem to behave like that. The logs will not show any trouble, other than the key addition failure. I speculate that FT transition results in a key mismatch between AP and client. Restarting Wifi will force a 4-way handshake and make it work again.

At home I use WPA3-SAE with 6 Linksys E8450 APs. SAE/PSK transitions are fast enough that it is easier to just turn off FT. I wish I could just disable FT in the iPhones instead of penalizing everyone else.

At work, we use WPA2-EAP without 80211w, using WRT3200ACMs and Archer C6 V2s, and the symptoms do not occur. BTW, it is an asymmetrical Mobility Domain, and see no trouble across mvebu (little endian) and ath79 (big endian) APs. In fact, I imagine that if there were a mismatch in mobility domains, then FT would not even be negotiated.

Here are this morning's transitions using an iPhone 11 at work:

$ grep -E -B16 'Jan  7.*(fe:43:19.*WPA.*auth)' hostapd.log | grep -E 'Jan  7.*(fe:43:19.*WPA.*auth|13[564].*key addition fail)'
Jan  7 08:11:23 wrt3200acm-5 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: start authentication
Jan  7 08:12:21 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 08:12:21 wrt3200acm-6 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 09:29:20 wrt3200acm-5 hostapd: nl80211: kernel reports: key addition failed
Jan  7 09:29:20 wrt3200acm-5 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 09:29:33 archerc6v2-4 hostapd: nl80211: kernel reports: key addition failed
Jan  7 09:29:33 archerc6v2-4 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 09:29:51 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 09:29:51 wrt3200acm-6 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 09:34:23 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 09:34:24 wrt3200acm-6 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 10:19:03 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 10:19:03 wrt3200acm-6 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 10:20:25 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 10:20:25 wrt3200acm-6 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 10:59:51 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 10:59:51 wrt3200acm-6 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 11:00:13 wrt3200acm-5 hostapd: nl80211: kernel reports: key addition failed
Jan  7 11:00:13 wrt3200acm-5 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 11:00:28 archerc6v2-4 hostapd: nl80211: kernel reports: key addition failed
Jan  7 11:00:28 archerc6v2-4 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 11:00:45 archerc6v2-4 hostapd: nl80211: kernel reports: key addition failed
Jan  7 11:00:45 archerc6v2-4 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 11:00:48 archerc6v2-4 hostapd: nl80211: kernel reports: key addition failed
Jan  7 11:00:48 archerc6v2-4 hostapd: wlan2g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake
Jan  7 11:01:40 wrt3200acm-6 hostapd: nl80211: kernel reports: key addition failed
Jan  7 11:01:40 wrt3200acm-6 hostapd: wlan5g: STA fe:43:xx:xx:xx:61 WPA: FT authentication already completed - do not start 4-way handshake

A full 4-way handshake was performed during initial connection, then all of the transitions were FT. The ones close to 11:00 happened while I roamed around a bit, pinging the default gateway. Most of the packet losses occurred while climbing up and down the stairs:

Sent: 161  Received: 151  Lost: 10  Loss: 6.21%
Min: 2.270  Avg: 26.250  Max: 604,416  Stddev 65.591

Packets dropped where numbered: 28, 29, 32, 33, 34, 68, 70, 71, 143, 155. I could not find a good correlation between the time of the failures and AP transitions. The 34 seconds between failures of packets 34 and 68 seem to be a good match for transitions at 11:00:28 (packets 32-34, wrt3200-5 5g to archer 2g) and 11:00:45-48 (packets 68-71, from archer 5g to wrt3200-6 5g then 2g). However, that last failure would have to be 20 seconds past my last transition, certainly after I had already stopped pinging.

2 Likes

This is really helpful thank you!

I have been using WPA2-PSK. Is WPA3-SAE any faster in terms of transition or just the same?

With iPhones and ipads connectivity seems OK, and fast transitions seem to get reported in the logs OK, but after some time (maybe 2 days?) my wife complains she has to manually disconnect and reconnect WiFi. I never see this issue with android devices / Windows laptop.

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 of the SSID; FT key is the md5sum of mobility_domain/radius_scret, and then used to set r0kh and r1hk with wildcard MACs and NAS identifiers. Beware that up to OpenWrt 21.02.xx, in case of PSK/SAE, the input is limited to 4 bytes (radius_secret will be empty), so it is safer to set your own key, but it will work without it nonetheless. From 22.03 onward, a 128-bit key will be generated from the mobility_domain & psk, and hostpad will then transform it into a 256-bit key.
Also, the transition will occur with any AP that uses that same key (nas_id and MAC will not be checked), which is not such a bit deal. If you wish to set your key with the wildcard MAC/nas_id, then use
ff:ff:ff:ff:ff:ff,*,Use-Your-Own-256bit-hex-key-here for r0kh (128-bit keys are
00:00:00:00:00:00,00:00:00:00:00:00,Repeat-Your-256bit-hex-key-here for r1kh

Support for 128-bit keys was maintained in hostapd for backward compatibility.

You may check /var/run/hostapd-phy* just to be sure everything is right:

mobility_domain=0123 # must be the same for all APs & interfaces
ft_psk_generate_local=0 # it will not work with WPA3 or EAP if not 0
nas_identifier=e89fxxxxxxd1 # this should be unique for every interface, default is the bssid
r0kh=ff:ff:ff:ff:ff:ff * 00112233445566778899aabbccddeeff # If using wildcard MAC/nas_id, this should be the same across all APs & interfaces within the same mobility domain
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 00112233445566778899aabbccddeeff # then this key should match the one in r0hk above
wpa_key_mgmt=SAE FT-SAE # It should have FT-SAE, FT-PSK or FT-EAP

Since this appears to be relevant 4 years after I wrote it, I edited the post in Feb/2024 to fix the example by using commas to separate keys from MACs, to point out the keys should be 256 bits long, and to update the status of default key-generation after OpenWrt 22.03.

TLDR: starting with OpenWrt 22.03, when not using WPA3, all you need to do to make FT work is to enable 802.11r from LuCI (option ieee80211r '1' in /etc/config/wireless). With WPA3, including mixed mode, you must disable "Generate PMK locally" in LuCI (option ft_psk_generate_local '0' in /etc/config/wireless).
With current snapshots, the Generate PMK locally option will be automatically disabled when using WPA3, and will not even show up in LuCI.

4 Likes

@cotequeiroz: Does this imply that 802.11r won't work without a controller (i.e. the common home scenario of at least two independent access points with no RADIUS, DAWN or other controlling server infrastructure)? If so, is this just a temporary restriction or is there something unsolvable in the way that WPA3 SAE works?

It works without a controller. It's just that you need to configure your key for r0kh and r1kh like in the example, and both APs must be reachable from the LAN network, I think. I have no idea why it does not work with WPA3 SAE--if it is something in the standard that keeps it from working as before, or if it needs something from someone's to do list. I haven't looked at this.

BTW, I've been running with WPA3-SAE and 802.11r here since I wrote my last post, and haven't got any complains about Apple devices not connected. They have been running just fine.

1 Like

cotequeiroz, am I reading your post correctly?

You have encryption set to SAE and 802.11r is fast roaming correctly?

I would like to get that working as well...