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