I've just found this thread and I'm wondering too.
Only on this forum there are threads where i.e. bss_transition is said to be set to 0 or others parameters.
I'm wondering if list above is complete (and why 802.11w has to be zero, as some clients may support it so why not "optional"?)
See this post in this thread from @hnyman. These are the configurations that provided the best results for me. However even so there are issues when roaming with Apple devices which does not seamlessly roam with 802.11r enabled.
I’ve discovered that all Android and Apple devices roams very well without 802.11r. So after multiple tentativas I’ve gave up on 802.11r which now is disabled in my 4 OpenWrt access points, and still all devices (including Apple devices) are roaming just fine.
Don't you see huge drops lasting like >100ms then? Enough to disrupt calls, etc.
Without 802.11r you will not have "fast transition". All devices will continue to roam, but the connection will be dropped, then re-established on a new AP.
1 Like
Right now I have "r" (and v, k also) and still fine tune configuration, although I can't get thru 3 AP's with simple ping running on my iPhone withouit seeing some packets dropped. I have more coverage than should, both 5 and 2.4 GHz.
Came here to find possible next tune-options to have it solved and not have WiFi call dropped while moving around house
So I had this thread that I created when I was running into similar issues. Through that I was directed to the settings in this thread.
On my particular iPhone 13, I don't see any dropouts anymore and the signal is constant. However, I have noticed dropouts on a 2019 iPad that is bit frustrating, although it's no where near as often as it was before those settings were introduced.
I definitely would go ahead with the configuration suggested if you're struggling with connection.
Edit, realised I replied to the wrong person
1 Like
Yes, I copied those into the config for my router and noticed a change basically straight away
1 Like
It doesn't have to be zero. I just recommended that for the following reasons:
- The recommended configuration is intended to support as many client devices and roaming features as possible while also being minimal (no additional packages/daemons like DAWN or usteer needed) and keeping problematic options disabled.
- Some client devices and chipset drivers have issues with 802.11w.
- WPA3 requires 802.11w and some client devices, chipset drivers, and possibly certain OpenWRT packages have issues with either/or.
- It works for me.
The intention was for people to try the minimal configuration, see if that gets them to a known-good state, and then to experiment from there. If you find enabling 802.11w and WPA3 works for you, then by all means, use it! Or if you want to introduce DAWN/usteer, try that!
If you have sufficient coverage with 5 GHz, try disabling 2.4 GHz altogether and see if that helps. I've noticed some devices (particularly a Google Pixel 2) will fast-transition from 2.4 to 5 just fine, but not the reverse.
If you need 2.4 GHz support for other devices, try adding a 5-GHz-only SSID and using that for the iPhone instead. You may also consider introducing DAWN/usteer at this point.
Edit to add: I just re-read your post and saw that you mentioned 802.11k being enabled. Have you tried without that? And with it, have you added a package/daemon that will actually prompt/collect the neighbor reports and send them out to the clients. Stock OpenWRT won't do that on its own.
It is possible that some devices may see that 802.11k is enabled, wait for neighbor configuration from the AP, never receive it, and thus roam poorly. I don't have evidence of this in actual implementation (since most of them are closed-source), but it's why I suggested leaving that disabled without an accompanying neighbor report daemon.
1 Like
With this you mean ntpd, or ntpclient?
I guess it's ntpclient to have time exactly synched?
--EDIT:
I started to dig further the time-thing and there's insteresting thread.
I don't know if it's fixed tho, but time seems to be important part of time advertisment
1 Like
I'm having a hell of a time getting devices to smoothly transition from one AP to another. All running OpenWRT 21.02, all with the same SSID and FT configured. FT actually works, but the network doesn't...
Something I learned about hostapd logging: you can turn on debug logging using
uci set wireless.radio0.log_level=1
but restarting hostapd (e.g. service hostapd restart) is not sufficient. I ended up doing service network restart and that finally regenerated the right config file so debug logging turned on.
The problem I'm having is that after my phone (pixel3a) switches to another AP it does not receive anything. It ARPs and pings (I'm running WifiMan signal mapper) and never receives a reply.
Here's what syslog says. Note "802.11: authentication OK (FT)". But 4 seconds after authenticating it disconnects and unless I'm misinterpreting something, that disconnect comes from the device.
Fri Sep 9 11:00:28 2022 daemon.err hostapd: nl80211: kernel reports: key addition failed
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: binding station to interface 'wlan1'
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: authentication OK (FT)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-AUTHENTICATE.indication(58:cb:52:38:a3:bb, FT)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: association OK (aid 2)
Fri Sep 9 11:00:28 2022 daemon.info hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: associated (aid 2)
Fri Sep 9 11:00:28 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 58:cb:52:38:a3:bb
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-REASSOCIATE.indication(58:cb:52:38:a3:bb)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: binding station to interface 'wlan1'
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: event 6 notification
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: FT authentication already completed - do not start 4
-way handshake
Fri Sep 9 11:00:32 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 58:cb:52:38:a3:bb
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: event 3 notification
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.1X: unauthorizing port
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: deauthenticated
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-DEAUTHENTICATE.indication(58:cb:52:38:a3:bb, 3
)
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-DELETEKEYS.request(58:cb:52:38:a3:bb)
Fri Sep 9 11:01:00 2022 cron.err crond[1079]: USER root pid 2920 cmd /root/iwinfo_stations.sh
I've done tcpdumps on the AP and on my router and the router receives the ARP requests and replies but the replies never show up at the ethernet port of the AP. I have relatively old D-Link Gbit smart switches and I'm wondering whether they are messing something up. I'm now working my way through port mirroring on the switches to determine where the reply packets end up... I'm using VLANs which adds yet another wrinkle to everything...
If anyone has seen anything like this and has suggestions I'm all ear! I know it's slightly tangential to FT but it's still part of the larger picture of "does fast roaming from one AP to another work?"
Learn to manually configure 802.11r roaming to work with WPA2 and WPA3, You'll own nothing and you'll be happy.
Generate a 128-bit key via SSH with the following command:
dd if=/dev/random bs=16 count=1 2>/dev/null | md5sum | awk '{print $1}'
Tutorial to learn how to manually configure 802.11r roaming:
https://www.reddit.com/r/openwrt/comments/515oea/finally_got_80211r_roaming_working/
Something like this: (All AP MACs have to be lowercase letters)
Configuration for AP 1 with BSSID 11:22:33:44:55:00 (AP 1 MAC):
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '0'
option nasid '112233445500'
option r1_key_holder '112233445500'
option pmk_r1_push '1'
list r0kh '11:22:33:44:55:00,112233445500,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:01,112233445501,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:02,112233445502,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:00,11:22:33:44:55:00,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:01,11:22:33:44:55:01,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:02,11:22:33:44:55:02,18880d5278d2eb37a744f5ab57bba6fb'
Configuration for AP 2 with BSSID 11:22:33:44:55:01 (AP 2 MAC):
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '0'
option nasid '112233445501'
option r1_key_holder '112233445501'
option pmk_r1_push '1'
list r0kh '11:22:33:44:55:00,112233445500,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:01,112233445501,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:02,112233445502,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:00,11:22:33:44:55:00,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:01,11:22:33:44:55:01,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:02,11:22:33:44:55:02,18880d5278d2eb37a744f5ab57bba6fb'
Configuration for AP 3 with BSSID 11:22:33:44:55:02 (AP 3 MAC):
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '0'
option nasid '112233445502'
option r1_key_holder '112233445502'
option pmk_r1_push '1'
list r0kh '11:22:33:44:55:00,112233445500,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:01,112233445501,18880d5278d2eb37a744f5ab57bba6fb'
list r0kh '11:22:33:44:55:02,112233445502,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:00,11:22:33:44:55:00,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:01,11:22:33:44:55:01,18880d5278d2eb37a744f5ab57bba6fb'
list r1kh '11:22:33:44:55:02,11:22:33:44:55:02,18880d5278d2eb37a744f5ab57bba6fb'
Or use this script to help you generate the configuration you need:
OpenWrt 802.11r FT roaming helper script:
1 Like
I do want to own things...
In the log I posted you can clearly see:
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: authentication OK (FT)
...
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: FT authentication already completed - do not start 4
So FT itself works. It's just that packets are not forwarded to the new STA. See also ongoing discussion in Android device disconnects after fast roaming due to lost DHCP replies - #7 by psherman
1 Like
Updated on 02/22/2023
I'm not sure if this will help you, but you can try this.
Paste via SSH these commands ONLY on your wireless access point devices:
(Do not paste it on the device that works as a router)
# ******* #
# Dumb AP #
# ******* #
# IP address for the dumb access point
DUMB_AP_IP="192.168.1.2"
# IP address of the main router
MAIN_ROUTER_IP="192.168.1.1"
##############################################
# Change the LAN interface protocol to "Static address", set the IP address for the dumb AP and disable the DHCP/DHCPv6 server
uci set network.lan.proto="static"
uci set network.lan.ipaddr="$DUMB_AP_IP"
uci set network.lan.netmask="255.255.255.0"
uci set network.lan.gateway="$MAIN_ROUTER_IP"
uci -q del network.lan.dns
uci add_list network.lan.dns="$MAIN_ROUTER_IP"
uci set dhcp.lan.ignore="1"
uci del dhcp.lan.ra
uci del dhcp.lan.ra_flags
uci del dhcp.lan.ra_slaac
uci del dhcp.lan.dhcpv6
uci del dhcp.lan.domain
uci del dhcp.lan.ndp
# Remove WAN and WAN6 interfaces
uci del dhcp.wan
uci del network.wan
uci del network.wan6
uci del firewall.@zone[1].network
# Disable these services because they do not run on dumb APs
for i in dnsmasq firewall odhcpd; do
if /etc/init.d/"$i" enabled; then
/etc/init.d/"$i" disable
/etc/init.d/"$i" stop
fi
done
# Disable daemons persistently
cat << "EOF" > /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# Disable these services because they do not run on dumb APs
for i in dnsmasq firewall odhcpd; do
if /etc/init.d/"$i" enabled; then
/etc/init.d/"$i" disable
/etc/init.d/"$i" stop
fi
done
exit 0
EOF
# Saving all modified values
uci commit
reload_config
Here are these guides for you to learn how to configure the dumb ap or mesh network correctly:
1 Like
I thought I'd follow up here on the resolution of my issues.
- I have 7 APs, all different models, that are now doing FT nicely.
- I do not believe the firewall/dnsmasq/odhcpd changes suggested by 72105 are necessary: 6 of my APs are running these services just fine, but what 72105 suggested caused me to rebuild the config of the problematic AP and that fixed something. My suspicion is with some VLAN stuff (it's a MicroTik hAP ac2 that has a built-in switch and some stuff is funky).
To see whether FT is working I highly recommend two things. First, turn debug logging for hostapd on:
uci set wireless.radio0.log_level=1
uci set wireless.radio1.log_level=1 // for dual-band AP
uci commit wireless
/etc/init.d/network restart
You will now see log lines where the following indicates FT:
Sat Sep 10 21:20:53 2022 [1662870053.646] daemon.debug hostapd: wlan1: STA 00:00:00:00:00:00 IEEE 802.11: authentication OK (FT)
...
Sat Sep 10 21:20:53 2022 [1662870053.696] daemon.debug hostapd: wlan1: STA 00:00:00:00:00:00 WPA: FT authentication already completed - do not start 4-way handshake
versus:
Sun Sep 11 00:31:33 2022 daemon.debug hostapd: wlan0: STA 00:00:00:00:00:00 WPA: sending 1/4 msg of 4-Way Handshake
Sun Sep 11 00:31:33 2022 daemon.debug hostapd: wlan0: STA 00:00:00:00:00:00 WPA: received EAPOL-Key frame (2/4 Pairwise)
Sun Sep 11 00:31:33 2022 daemon.debug hostapd: wlan0: STA 00:00:00:00:00:00 WPA: sending 3/4 msg of 4-Way Handshake
Sun Sep 11 00:31:33 2022 daemon.debug hostapd: wlan0: STA 00:00:00:00:00:00 WPA: received EAPOL-Key frame (4/4 Pairwise)
The second recommendation, if you have an Android phone, is to use the Ubiquiti WiFiMan app:
- When you open it, hit "wireless" bottom center. Then select your SSID and you'll see all your APs.
- Then select "signal mapper". This shows you signal strength and latency to 8.8.8.8.
- In addition, and this is the interesting part, it shows you the AP transitions at the bottom.
When the device roams from one AP to another you either see
AP1 --> AP2
which means FT, or you see
AP1 --> disconnected
disconnected --> AP2
which means 4-way-hs. You can then walk around and see where signal strength drops off and when the device roams and how it does it.
For completeness, here's a typical /etc/config/wireless interface config on my APs:
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option ssid '*****'
option max_inactivity '20'
option encryption 'psk2+ccmp'
option key '********'
option ieee80211r '1'
option mobility_domain 'f00d'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option network 'lan'
9 Likes
Thank you for sharing your findings. Although while checking with WiFi man and logs I see device 'roams', but it does it with huge signal drop and dead connection between 1st and 3rd floor, while there's AP in the middle while going on stairs fully available... So will still debug further.
You have all other options lest as default? No 802.11w/k/v blank?
And Wi-Fi channels between those 7 APs - I guess they are all different or you keep them on the same channel?
Do you use same SSID for 2.4 and 5 network?
I can also see you lack 'nasid' which is marked as required within documentation?
This setting should works for WPA2-PSK and 802.11r, it should works in most case (although not most secure)
Just share here in case someone need it.
openwrt 21.02.3
Encryption: WPA2-PSK
Cipher: Force CCMP (AES)
NAS ID (AP1): APONE
NAS ID (AP2): APTWO
Mobility Domain: bc23
Reassociation Deadline: 20000
FT Protocol: FT over the air
Generate PMK locally: True
802.11w management frame protection: optional or I suggest turn off (maximum compatibility)
KRACK protection: True
2 Likes
Everything else is default and the AP channels are relatively diverse. I use 1/6/11 and 36/42/149/157 (40Mhz). I do now inject the rrm neighbor's information into hostapd, but that's really an optimization and not necessary for basic FT functioning.
The NasID is unset 'cause I use WPA2-PSK (the UI states "Not needed with normal WPA(2)-PSK.")
I do have issues around the house entrance where taking a step around a corner ought to switch between 2 APs and sometimes the phone does and sometimes it doesn't. In your case, ensure you can FT to all the bands of all the APs before trying to deal with the problem spots.