802.11r Fast Transition how to understand that FT works?

Fiouz · 2021-11-06T05:10:30.770Z

wpad-openssl, as I switched from default WolfSSL to OpenSSL.

Here is my relevant diffconfig section in case you want to build your own:

## Wireless
# CONFIG_WPA_WOLFSSL is not set
CONFIG_WPA_MSG_MIN_PRIORITY=4
CONFIG_PACKAGE_hostapd-utils=y
# CONFIG_PACKAGE_wpad-basic-wolfssl is not set
CONFIG_PACKAGE_wpad-openssl=y
# CONFIG_PACKAGE_iw is not set
CONFIG_PACKAGE_iw-full=y

seemebreakthis · 2021-11-06T06:38:34.062Z

I am using 802.11r and it works in my network setup. Thought I'd share some of my experience with you...

I have two routers (of the same brand and model), one being the gateway and other acting as an AP extension. My log (when a client fast transitions to another AP) do not show "FT authentication already completed..." either. But I recall seeing it before, so I have reason to believe this is due to the verbose level. Here is my log (take note of the time):

AP router (transitioning away in this case):

Sat Nov  6 14:02:20 2021 daemon.notice hostapd: wlan0-1: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sat Nov  6 14:02:25 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request

Gateway (transitioning to in this case):

Sat Nov  6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Sat Nov  6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 6)
Sat Nov  6 14:02:20 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Sat Nov  6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)

And I have a way to really easily test for normal 802.11r operations:

On my Android phone, I start KODI, then play a video from local network drive. You can do something like this, or even start copying a file from network drive via SMB etc to your local device - just make sure this is a process that will get interrupted (i.e. not buffered and it won't make attempts to reconnect) if network connection is broken.
On the router to which this device is currently connected, go to LUCI then in "status" -> "overview", just go ahead and press the disconnect button for this device
If 802.11r is working properly, the other router will pick up the connection right away (assuming it is within coverage), and whatever the process is being run on the device at the moment (video playback, file copy, etc) will continue without interruption.
Wait at least 3 minutes (otherwise the original router will just reject the connection attempt), then do the same thing on LUCI of the other router. You should see the connection jumping back to the original router, and since 802.11r is working, the process on the device will once again continue without interruption.

A couple of additional notes:

I have not changed wpad at all, just using whatever wpad that comes with the OpenWrt installation. I checked, it is wpad-basic-wolfssl. I am using OpenWrt 21.02.1.
My two routers were connected with relayd before. And 802.11r was hit and miss for other devices, and did NOT work for my Android phone at all. I changed to WDS, and this made 802.11r work consistently for all of my devices that support it. And this was back when my routers were running 19.07. With 21.02 the entire connection has been even more stable, fast transitioning included.

(edit: I specifically said KODI above because I saw other apps that will quietly make re-connection attempts then resume playing. I believe VLC acts like that if I recall correctly. My KODI just continues to play the video file with zero pause or interruption, but if 802.11r is disabled, it drops the connection entirely)

ZebraOnPC · 2021-11-06T06:55:10.019Z

You should make log level =1 and you will see 4 steps handshake . No FT.
Your log level doesn't show everything.
I have the same log before I change the level .
My phone works absolutely the same if 802.11r is enabled or not , both AP have the same SSID same encryption and same passwords.
And as you can see on the picture

Screenshot_20211106-034317720×1280 65.8 KB

no disconnect and no FT
Also as you can see the APs have FT

Screenshot_20211106-095731720×1280 88.4 KB

seemebreakthis · 2021-11-06T07:31:54.623Z

Hmm.. you are right. Changed log level, and my log does show the whole 4-way handshake being done.

Bookmarking this thread. If a solution is found maybe it will help me too...

(I thought all along if there is no connection interruption then it means 802.11r is working)

ZebraOnPC · 2021-11-06T07:40:04.073Z

FT is all about make lees the switch time to 50ms , my phone switches for 200ms even with 802.11r off , but if APs have different SSID it is always like 1-5 seconds,
I've tried everything with setting and packagesI think, but I never tried new phones like 2018 and new, main is 2016 I think

hnyman · 2021-11-06T07:40:54.429Z

ZebraOnPC:

as you can see on the picture

Screenshot_20211106-034317720×1280 65.8 KB

no disconnect and no FT

@ZebraOnPC
From which wifi analyzer / heatmap app that screenshot with the clear "access port roaming" log is?

ZebraOnPC · 2021-11-06T07:43:30.746Z

It is from wifiman ubiquity blue icon with white wifiman on it

seemebreakthis · 2021-11-06T08:02:39.472Z

Good luck, hope you can find a solution so I can apply it to my setup also.

And thanks for enlightening me with "Wifiman", this is clearly a better way to test wifi roaming. (I guess I am now at a similar situation as yours - switching for 200ms)

Stefan1 · 2021-11-06T10:19:06.555Z

How do you measure these 200ms ?

Stefan1 · 2021-11-06T11:48:54.309Z

I tried out the latency measurement in wifiman while roaming with my Samsung S20 FE.
In our house we have one AP at ground level, and one AP 2 levels above.

The samsung device is sticky and roams only once you reach the level of the other AP, the signal needs to drop to around -75dB or less.

With use of only 2.4 GHZ on both AP, the latency goes up as the signal needs to pass concrete ceilings,... so it goes up from 24ms to about 120ms.
Then the roaming process brings up the ping times to 250ms, sometimes even 400ms. After roaming has happened, ping times go down again...

With 5GHz only the ping times consistently stay at 25ms, even during the roaming process. There is hardly any effect of roaming on ping times visible. Sometimes they might go up to 50ms, but not always.

Question is of course, how frequently the pings are measured. But it looks like the latency of a bad 2.4 ghz signal has a bigger influence than the roaming time.

Maybe this effect is also caused by the Samsung device, as it seems to generally connect to 5ghz faster than to 2.4ghz wifi.

Btw the roaming time with 2.4 ghz was independent of the existency of the 5 ghz wifi. If the target network for roaming is 2.4 ghz, it is relatively slow, if it is 5ghz, it is fast ( also when coming from a 2.4 ghz network).

Btw all roamings happened with FT over DS, I checked the logs no full handshakes happened...

hnyman · 2021-11-06T14:14:05.788Z

Just documenting here, that I got the 802.11r functioning after I increased the reassociation_deadline to 20000 (from the default of 1000), based on advice from the discussions at

Rekeying Issue - “driver can’t safely do that.” - #18 by dsouza
and
https://bugs.openwrt.org/index.php?do=details&task_id=3159
.

My Android 11 tablet roamed between

ipq806x/R7800 with ath10k-ct wifi in 802.11ac mode (VHT160)
mt7622/RT3200 with mt76 wifi in 802.11ax mode (HE80)

(So the even AC/AX mode difference does not hurt...)

I changed from my normal WPA2/WPA3 mode to the plain WPA2, as some advice suggested that 802.11r does not play well with the WPA2/WPA3 mixed mode.

Using that "Signal mapper" screen from Ubiquiti's Wifiman app helped a lot to notice the roaming actions.

Settings that worked for me:

        option log_level '1'

        option encryption 'psk2'
        option ieee80211r '1'
        option mobility_domain '2222'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

daemon.debug hostapd: wlan0: STA e0:...:30 WPA: FT authentication already completed - do not start 4-way handshake

Details:

R7800 settings

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option country 'FI'
        option log_level '1'
        option cell_density '0'
        option txpower '21'
        option channel '100'
        option htmode 'VHT160'
        option disabled '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxxxxxxx'
        option key 'xxxxxxxx'
        option wpa_group_rekey '13600'
        option ieee80211w '1'
        option encryption 'psk2'
        option ieee80211r '1'
        option mobility_domain '2222'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

RT3200 settings

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option band '5g'
        option cell_density '0'
        option country 'FI'
        option htmode 'HE80'
        option channel '44'
        option log_level '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option key 'xxxxxxxxx'
        option ieee80211w '1'
        option ssid 'xxxxxxxx'
        option encryption 'psk2'
        option ieee80211r '1'
        option mobility_domain '2222'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

Log extracts

RT3200:

root@router4:/etc/config# logread -f
Sat Nov  6 15:41:18 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan1'
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: authentication OK (FT)
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 MLME: MLME-AUTHENTICATE.indication(e0:c3:77:ae:0a:30, FT)
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: association OK (aid 1)
Sat Nov  6 15:41:18 2021 daemon.info hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: associated (aid 1)
Sat Nov  6 15:41:18 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED e0:c3:77:ae:0a:30
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 MLME: MLME-REASSOCIATE.indication(e0:c3:77:ae:0a:30)
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan1'
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 WPA: event 6 notification
Sat Nov  6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 WPA: FT authentication already completed - do not start 4-way handshake

R7800:

root@router1:/etc/config# logread -f
Sat Nov  6 15:41:42 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED e0:c3:77:ae:0a:30
Sat Nov  6 15:41:42 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: authentication OK (FT)
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 MLME: MLME-AUTHENTICATE.indication(e0:c3:77:ae:0a:30, FT)
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: association OK (aid 2)
Sat Nov  6 15:41:42 2021 daemon.info hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: associated (aid 2)
Sat Nov  6 15:41:42 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED e0:c3:77:ae:0a:30
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 MLME: MLME-REASSOCIATE.indication(e0:c3:77:ae:0a:30)
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 WPA: event 6 notification
Sat Nov  6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 WPA: FT authentication already completed - do not start 4-way handshake

ZebraOnPC · 2021-11-06T19:59:10.180Z

I just read about the roaming with the same SSID and password

ZebraOnPC · 2021-11-07T00:58:14.233Z

but i dont see in your config parametrs such us

option nasid 'F85E3C1CDA6A'
option r1_key_holder 'F85E3C1CDA6A'
option pmk_r1_push '1'

and i have Android 7 maybe Android 7 doesn support 802.11r... i cant find

hnyman · 2021-11-07T05:57:36.121Z

I left all of them empty, to be filled automatically, or to be used at default values.

ZebraOnPC · 2021-11-07T08:04:17.271Z

IMG_20211107_105951720×421 68.5 KB

I think this picture says that there supposed to be only one router that makes PMK-R1 keys for other AP and for itself , so settings supposed to be different on 1 router and other routers that
not create these keys (at least 1 option)
But maybe it is only with special controllers

hnyman · 2021-11-07T08:15:11.598Z

ZebraOnPC:

I think this picture says that there supposed to be only one router that makes PMK-R1 keys for other AP and for itself

Well, we use automatics since the commit below, and all those values get calculated from the SSID etc.

github.com/openwrt/openwrt

hostapd: fix IEEE 802.11r (fast roaming) defaults

committed 09:19AM - 18 May 18 UTC

devianceluka

+27 -21

Use ft_psk_generate_local=1 by default, as it makes everything else fairly trivi…al. All of the r0kh/r1kh and key management stuff goes away and hostapd fairly much does it all for us. We do need to provide nas_identifier, which can be derived from the BSSID, and we need to generate a mobility_domain, for which we default to the first four chars of the md5sum of the SSID. The complex manual setup should also still work, but the defaults also now work easily out of the box. Verified by manually running hostapd (with the autogenerated config) and watching the debug output: wlan2: STA ac:37:43:a0:a6:ae WPA: FT authentication already completed - do not start 4-way handshake This was previous submitted to LEDE in https://github.com/lede-project/source/pull/1382 [dwmw2: Rewrote commit message] Signed-off-by: Gospod Nassa <devianca@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Note that instead of automatics, I explicitly used mobility domain 2222, which is byte-symmetrical in case there is possibly bigendian/littleendian trouble between different routers, like pondered in

802.11r mobility domain byte order Installing and Using OpenWrt

Hi, I am new user of openwrt and this looks grate software. I am trying to join openwrt box on existing 802.11r network by CISCO WAP series. FT seems not to work properly from cisco's log. I capture beacon frame of both box and found that openwrt's mobility domain swaps byte order. My mobility domain is 10000 as decimal and 0x2710 as hex. CISCO sends it as little endian and wireshark recognize as 0x2710. OpenWRT sends it as big endian and wireshark recognize as 0x1027. Which endian is tr…

Stefan1 · 2021-11-07T08:45:53.875Z

According to this link, the honor 6a does not support 802.11r:

inside digital

Huawei Honor 6A Datenblatt | alle technischen Daten

Alle technischen Daten und Features des Huawei Honor 6A ✓ Hier findest du alle Daten, Tests und Preise zum Huawei Honor 6A. Jetzt informieren und vergleichen!

only
IEEE 802.11b
IEEE 802.11g
IEEE 802.11n
are listed

hnyman · 2021-11-07T09:05:04.958Z

ZebraOnPC:

my honor A6

Stefan1:

According to this link, the honor 6a does not support 802.11r

Those mentioned b/g/n on the linked site are just the major wifi connectivity generation standards (like the newer ac and ax).
I doubt that the site would list all the minor 802.11? feature letters like k,r,v,w.

But in a a sense you are right, e.g. Samsung is vague and mainly says that most phones work since Android 9 (Pie) onward. In addition to the Android itself, it is about the specific wifi chipset in the phone and its driver's capabilities.

802.11r support in Android 7 sounds questionable. Possibly it is not found in most of the Android 7 phones.

Stefan1 · 2021-11-07T09:36:47.799Z

hnyman:

I doubt that the site would list all the minor 802.11? feature letters like k,r,v,w.

I agree. Anyhow before again changing the AP settings I would try with a client that is known to work with 802.11r.

ZebraOnPC · 2021-11-07T10:14:25.408Z

IMG_20211107_131132720×962 111 KB

I found a site where I can see almost any phone with all parameters ,this one is samsungS20 The site
so ive cheked 4 phones none has 80.2.11r