802.11r Fast Transition how to understand that FT works?

Recently i got new phone on Android 11, set up new device with
wpad-basic 2019-08-08-ca8c2bd2-7 296.7 KB on it and did minimal setting


And everything works

Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 MLME: MLME-REASSOCIATE.indication(06:c9:b3:6f:db:49)
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 WPA: event 6 notification
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 WPA: FT authentication already completed - do not start 4-way handshake

works the same with Over DS or Over The Air

I have been able to make 802.11r work - it was a long process and would not have been possible without the help of the forum here and Reddit posts - my setup is a bit more complicated as I use multiple tagged vlans and Radius auth for one of the SSID. I hope the following will help people trying to get this going. All this was done using 21.02.1 - I replaced iw with iw-full and use hostapd-wolfssl - as this is a dumb AP wpad is not used - I am not sure if the iw change is required - I need full hostapd as I use Radius auth.

Let me start by saying that the Gui 'automatic' setup just did not work for me - there are many people that say it does, I am am sure it does for many, but I wonder if people test it properly - by far the best method I found for Android is to use the WiFiman app - select Signal Mapper, and walk around - if you see BSSID to BSSID transitions it is working fine. If you see Disconnected to BSSID transition in WiFiman, 11r is NOT working.

If you don't have access to Android, your next best option is to enable level 1 debug for hostapd process and look for the FT string. Again please note you need to verify that the client you are using for testing does support 802.11r - without that you might be wasting your time ( see below how to test your client ).

Here are the steps I took to make my setup work:

  • Test my clients for 802.11r support ( used both Android 11 and 12 ) using profiler script
  • Obtain BSSID for all the SSID used for roaming on all access points used
  • Generate config using helper.py script
  • Update /etc/config/wireless and restart with wifi reload command
  • Test using WiFiman or enable loglevel 1 for hostapd
  1. Testing clients - in my case I used Kali Linux and follow the steps on link - the only problem I run into was that my newer Wifi adapter was not supported - otherwise it does work and can generate fair bit of info - the output is saved in /var/www/html/profiler

  2. Obtain BSSID - I have two APs, each with 3 SSID, on both 2.4 and 5Ghz - right now only one SSID is used for roaming ie used by mobile devices - the others are for fixed IOT devices - in my case the wlan0 and wlan1 are assigned - to avoid mistakes with MAC addresses I would recommend to cut&paste. The command I used to quickly find the relation between SSID and BSSID was:

ssh to AP
egrep '^(ssid|bssid|interface|bss)=' /var/run/hostapd-phy*.conf
  1. Generate config using helper.py (link)- it will create output that can be used with uci or added directly to the wireless config - I used the config method
On any system that can run Python3
cd /tmp
wget https://raw.githubusercontent.com/walidmadkour/OpenWRT-UCI-helper-802.11r/master/helper.py
chmod +x helper.py
./helper.py 0 -ap XX:XX:XX:XX:XX:XX -ap YY:YY:YY:YY:YY:YY -ap ... --format config
  1. Ssh to your AP and use the output of the above command to update the wireless config - please make sure to match the correct SSID with the helper output - also I needed to add the following options to each SSID used for roaming:
vi /etc/config/wireless
config wifi-iface 'wifinetX'       
        ...
        option reassociation_deadline '20000'                                           
        option ft_over_ds '0'                                                           
        option ft_psk_generate_local '0'     
wifi reload
  1. Test - as mentioned before WiFiman was the simplest way to test it as it clearly shows when roaming - you will see BSSID to BSSID transitions under the Signal Mapper button - to get there:
  • connect your phone to the SSID used for roaming
  • start Wifiman
  • select Wireless menu - will display list of all networks
  • select your SSID
  • you should see a blue button 'Signal Mapper' - if you don't see the button, you have not selected the SSID your phone is connected to.

As with any problem, once you have a working solution it, it is much easier to go back - you can look at removing some things from the config, and even trying the Gui method - I would backup the /etc/config/wireless file - at least the manual method does work and is a good starting point for people that are having difficulty getting 802.11r going - good luck.

7 Likes

@xman Thanks for that. I've been wondering how to test 802.11r with my WRT1900ACS and WAC104.

I have a Pixel 6 and the "automatic" setup. WiFiman is showing BSSID to BSSID transitions without any disconnects.

I did some basic tests, and I need to test more. But I`ve found that Android is fast roaming OK, and iPhone and Windows are not OK.

It is quite possible that the client wifi drivers do not really support 802.11r

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:

2 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