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...
Basically, assuming you're running 21.02 or master and configuring from luci, you just need to turn 802.11r on and disable 'Generate PMK locally'. Leave the r0kh and r1kh empty.
OpenWrt will generate a key for you. Test it with just that to see if it works. The caveat is that it will only use the mobility domain to do so, meaning it will only generate 65536 possible keys, vs 3.403E+38 if you set your own. If you don't set your own mobility domain, then anyone can use the same recipe to compute the key from your SSID, which is not good. I have sent a patch to append the PSK, which should be safe, but it has not been accepted yet.
Then a recommended next step is to setup your own 128-bit key to use for r0kh and r1kh. Running this will generate a random one for you:
dd if=/dev/random bs=16 count=1 2>/dev/null | md5sum | awk '{print $1}'
05ad9451dcaa84f746311694186c29e7
Using 05ad9451dcaa84f746311694186c29e7 as an example, then set:
- r0kh to:
ff:ff:ff:ff:ff:ff * 05ad9451dcaa84f746311694186c29e7 - r1kh to:
00:00:00:00:00:00 00:00:00:00:00:00 05ad9451dcaa84f746311694186c29e7
This exact setup--the key has to be the same--should be used across all your wireless interfaces in all APs doing 802.11r for the same SSID (technically, it's the same mobility domain).
6 Likes
Anyone got problems with Apple devices sometimes not playing well with FT (my wife keeps complaining that she has to disable and re-enable WiFi now and then - perhaps after a long period of inactivity, but I am not sure)? I think this is only Apple because I don't see the issue on my android devices.
Is there a solution?
I used to have the exact same problem, then out of the blue--or most likely, a config change that I don't remember--they were gone.
I have 5 iPhones (X, XR, 11) regularly in my network of 6 Linksys E8450 running master from dec/2021 (7e89421a7c). I turned 802.11r on January 7, and have been running smoothly ever since.
I use WPA3/SAE, and have 802.11{w,r,k,v} on. DAWN fills up neighbor reports (don't know if that helps with FT). Perhaps ft_psk_generate_local 0 may make a difference. Here's my full config:
config wifi-iface 'Xxx_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'Xxx'
option encryption 'sae'
option key '***'
option ieee80211w '2'
option ieee80211r '1'
option ft_psk_generate_local '0'
option ft_over_ds '0'
option ieee80211k '1'
option bss_transition '1'
option ieee80211v '1'
option disassoc_low_ack '0'
I don't have r0kh or r1kh set because I'm running my patch to compute them from psk. You may want to set them manually.
I also run a legacy SSID with WPA2-PSK, but I don't think I have Apple devices connected to it regularly. It has ft_psk_generate_local '1', and ieee80211w '1', but I can't say if it works or not.
Thanks for the tips!
Its interesting and frustrating how few of my devices support fast roaming...
My pixel3a will fast roam with PSK2 but not SAE. When I am using SAE the pixel3a locks onto an AP and will not let go until the signal is gone.
Windows 10 does not support 80211r on PSK networks.
My family has various iphones, and I tested one and I think 80211r was working, I need to test it further.
My chromebook will not connect to an SAE network.
My macbook pro m1 from 2020 seems to use 80211r with SAE fine.
So I seem to have it working for apple devices at least.
Here is what I have:
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'XXXX'
option encryption 'psk2'
option key 'XXXX'
option wds '1'
option ieee80211r '1'
option ft_psk_generate_local '1'
option reassociation_deadline '20000'
option ft_over_ds '0'
@netprince yes my Pixel 3a (what a great device) is very happy with FT on PSK2. Works perfectly all the time. And I have confirmed multiple times FT's throughout the house between 3x RT3200's. I have not tried SAE. It sounds like that is going to break my Pixel 3a or older devices. So stuck between rock and hard place?
I think my wife has an iPhone 13 and that seems to not be working with my PSK2 setup. When I say not working I need to qualify this. When I test it, it works fine. I see the fast transitions as I walk around the house and have confirmed with the right level of logging:
The problem is that now and then the iPhone needs to be manually reconnected. It's hard to reproduce.
@hnyman suggested some ideas to get the iPhones to work here:
Could it be something related to inactivity polling:
Certainly I think the issue relates to use following a lengthy period of inactivity. My wife picks up phone from charge and observes no WiFi, and has to manually disable and re-enable.