802.11r Fast Transition how to understand that FT works?

In the AP logs you should see entries like this:

WPA: FT authentication already completed - do not start 4-way handshake

Walking around with the phone, you should see in Wifi Analizer that the highlighted network (the one the phone is currently associated to) keeps the same SSID, but different MAC address and -possibly- channel.

Starting a Ping from a terminal console to your local gateway (or to a host in your network) you should lose just a few packets while roaming

1 Like


On each router the same SSID but deferent BSSID
Also you can see all 3 signals have the same name (SSID)on the screenshot earlier , but
I don't have

WPA: FT authentication already completed - do not start 4-way handshake

In my log file. What did a wrong I don't know and I don't know how to figure it out

I would try to set "generate pmk locally" on first.
Make sure mobility domain is the same on all APs.
Then you could try to separate the channels.
Apparently the signal levels are pretty close from the screenshot you posted.
It's up to the client choosing if and where to roam to.

1 Like


They are on the same channel (11)
Mobility domane is the same

A Grand Prime also displays + FT and fails to connect.

You may need to increase the log verbosity, see:

Here what a the log would look like:

Fast transition log
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan0'
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK (FT)
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx MLME: MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, FT)
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: association OK (aid 3)
Thu Nov  4 10:37:42 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 3)
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx MLME: MLME-REASSOCIATE.indication(xx:xx:xx:xx:xx:xx)
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan0'
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 6 notification
Thu Nov  4 10:37:42 2021 daemon.debug hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: FT authentication already completed - do not start 4-way handshake

(note: I may have extra logs as I have some custom build options)


Edit: after reading your log again, it seems it is not working for you, as it performs a complete handshake:

OP logs
Wed Nov  3 21:48:46 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 70:8a:09:df:f1:bc
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc IEEE 802.11: authentication OK (open system)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: event 0 notification
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc MLME: MLME-AUTHENTICATE.indication(70:8a:09:df:f1:bc, OPEN_SYSTEM)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc MLME: MLME-DELETEKEYS.request(70:8a:09:df:f1:bc)
Wed Nov  3 21:48:46 2021 daemon.info hostapd: wlan0: STA 70:8a:09:df:f1:bc IEEE 802.11: authenticated
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc IEEE 802.11: association OK (aid 1)
Wed Nov  3 21:48:46 2021 daemon.info hostapd: wlan0: STA 70:8a:09:df:f1:bc IEEE 802.11: associated (aid 1)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc MLME: MLME-REASSOCIATE.indication(70:8a:09:df:f1:bc)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc MLME: MLME-DELETEKEYS.request(70:8a:09:df:f1:bc)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc IEEE 802.11: binding station to interface 'wlan0'
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: event 1 notification
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: sending 1/4 msg of 4-Way Handshake
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: received EAPOL-Key frame (2/4 Pairwise)
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: sending 3/4 msg of 4-Way Handshake
Wed Nov  3 21:48:46 2021 daemon.debug hostapd: wlan0: STA 70:8a:09:df:f1:bc WPA: received EAPOL-Key frame (4/4 Pairwise)
1 Like

On a side note, I believe you should not use same/overlapping channels between your APs, STAs will otherwise compete for air time, and hinder performance.

On the 2 GHz band, spreading your APs between the 1/6/11 channels is a common practice (those 3 channels do not overlap).

2 Likes

I did these commands to set up the level of log to 1

root@ap10:~# cat /var/run/hostapd-phy0.conf                                            driver=nl80211                                                                         logger_syslog=127                                                                      logger_syslog_level=1                                                                  logger_stdout=127                                                                      logger_stdout_level=1                                                                  country_code=RU                                                                        ieee80211d=1                                                                           hw_mode=g
beacon_int=100
channel=11



ieee80211n=1
ht_coex=0
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC12]

interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
nas_identifier=78a3517bfa54
wpa_passphrase=1225612256
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=AvngMesh
bridge=br-lan
mobility_domain=aaaa
ft_psk_generate_local=1
ft_over_ds=0
reassociation_deadline=1000
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK FT-PSK
okc=0
disable_pmksa_caching=1
bssid=78:a3:51:7b:fa:54

This is my config
Can you compare to your config say if there is some difference in parameters .
But why it always makes full handshake can it be because of my phone I have android 7

diff hostapd-phyX.conf
3a4
> basic_rates=60 120 240
5c6
< bridge=br-lan
---
> bridge=br-IoT
8a10
> chanlist=11
9a12,13
> config_id=ec24c2e360794d3055db2516551624fc
> country_code=<REDACTED>
13c17,21
< ft_over_ds=0
---
> driver=nl80211
> dtim_period=2
> dynamic_vlan=0
> ft_iface=br-IoT
> ft_over_ds=1
15c23,24
< ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC12]
---
> group_mgmt_cipher=AES-128-CMAC
> ht_capab=[HT40-][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
16a26,27
> hw_mode=g
> ieee80211d=1
17a29
> ieee80211w=1
19c31,35
< interface=wlan0
---
> interface=wlan1
> logger_stdout=127
> logger_stdout_level=1
> logger_syslog=127
> logger_syslog_level=1
24a41
> radio_config_id=e73a97bcf552b8f445f7ae1d9f0d395a
25a43,44
> skip_inactivity_poll=0
> snoop_iface=br-IoT
26a46
> supported_rates=60 90 120 180 240 360 480 540
28a49,52
> vlan_file=/var/run/hostapd-wlan1.vlan
> vlan_naming=1
> vlan_no_bridge=1
> wds_bridge=
31,32c55,56
< wpa_disable_eapol_key_retries=0
< wpa_key_mgmt=WPA-PSK FT-PSK
---
> wpa_disable_eapol_key_retries=1
> wpa_key_mgmt=WPA-PSK FT-PSK WPA-PSK-SHA256
34a59
> wpa_psk_file=/var/run/hostapd-wlan1.psk
uci show wireless.radio1
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.hwmode='11g'
wireless.radio1.path='soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
wireless.radio1.country='<REDACTED>'
wireless.radio1.htmode='HT40'
wireless.radio1.txpower='8'
wireless.radio1.channel='11'
wireless.radio1.cell_density='0'
wireless.radio1.log_level='1'
uci show wireless.default_radio1
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.mode='ap'
wireless.default_radio1.encryption='psk2+ccmp'
wireless.default_radio1.ft_over_ds='1'
wireless.default_radio1.ft_psk_generate_local='1'
wireless.default_radio1.ieee80211r='1'
wireless.default_radio1.ieee80211w='1'
wireless.default_radio1.wpa_disable_eapol_key_retries='1'
wireless.default_radio1.key='<REDACTED>'
wireless.default_radio1.ssid='<REDACTED>'
wireless.default_radio1.network='IoT'
1 Like

Obviously in your hostapd config ft_over_ds is switched off.

My config is more complex, as I use radius authentication, but the setup in the ui should be as described here:

1 Like

well i am starting to think maybe my smartphone doesnt support 802.11r
it is huawei nonor 6A
it roams good even if 802.11r is disabled but have the same SSID

Can it be possible that 802.11r simply doesnt work without RADIUS server ?
I don't have one I just use wpa-psk

My setup is without RADIUS, just WPA2-PSK, but I forgot to mention my logs/config are from the master branch (latest development, even newer than 21.0.1), and I haven't tested OpenWrt 19.

1 Like

Thanks , looks like I must try the master branch .
What package u use ?
wpad
wpad-basic ?

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
1 Like

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:

  1. 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.

  2. 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

  3. 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.

  4. 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:

  1. 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.

  2. 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)

4 Likes

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


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

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)

1 Like

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

1 Like

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

1 Like