Any way to monitor if 802.11r is working?

Installing and Using OpenWrt Network and Wireless Configuration
#1

I've set up 3 APs all running the same OpenWRT version (a recent master build), on different channels, same SSID and password, same network settings, etc. I've enabled 802.11r on all of them, just checked the box in Luci, didn't customize anything else.

Now the question is how do I know whether it's working? Is there anything I can monitor on the APs, in the logs? Or just observe the client behavior? I have a 2018 MBP and it doesn't seem to roam as I get closer to an AP it still stays connected to the farthest one, but perhaps it thinks the signal is good enough to not need to roam.

#2

You can enable debug level hostapd log and check syslog for below messages.

IEEE 802.11: authentication OK (FT)
WPA: FT authentication already completed - do not start 4-way handshake

Client should start 4-way handshake only when it first associating at the AP and when steering/switching over same SSID, it should be 2-way handshake FT (802.11r fast transitioning) stating in above messages.

edit: yes you just click on enable 802.11r but when doing on different devices just make sure they have the same mobility domain, as well as same SSID and password set.

2 Likes
#3

Thank you. How do I enable hostapd debug?

I did not set mobility domain at all, Luci has a grayed out value of 4f57 same on all APs. My understanding is that if I don't set it it will be autogenerated as a hash of the SSID so if the SSID is the same everywhere it should end up having the same value. Is the recommendation to just force set it to some value? I'm not sure if 4f57 is what the value ends up being or it's just a Luci UI hint for the format (the value is not in /etc/config/wireless).

Edit: I should mention I have 2 SSIDs on the same radio and I want them both to fast transition (not between the 2 SSIDs but within the same domain). Is it OK to leave the mobility domain blank or will they get confused?

#4

It is not blank as luci sets a default value, so you don't need to but it should be the same value with other devices you have.

uci set wireless.default_radio0.logger_syslog_level=1
uci set wireless.default_radio1.logger_syslog_level=1
uci commit

Restart your wireless bands and then look at hostapd-phy0.conf and hostapd-phy1.conf if thats parsed into with cat /var/run/hostapd-phy0.conf. If not, then you must edit the hostapd.sh file located in /lib/netifd/ and change that value manually to 1 there.

In latest versions, 802.11r roaming works out-of-the-box with openwrt.

edit: Btw, you can also test this with mobile client app called Ubiquiti WiFiman, start monitoring and you can see your phone roaming AP to AP in history log.

#5

Wouldn't mobility_domain be present in /etc/config/wireless then? It is not, but if I force a value an option mobility_domain shows up in the file. It doesn't appear that Luci sets anything by default, it must default somehow.

I will try your tips about logging, thanks.

#6

not necessarily, in etc/config/wireless, only your commits are written. default values are already parsed into other related config files.

1 Like
#7

I tried some things and here are my observations.

To enable logging:

uci set wireless.radio0.log_level=1
uci set wireless.radio1.log_level=1
uci commit wireless
wifi up

mobility_domain ends up in /var/run/hostapd-phy*.conf but it's not the grayed out value that's displayed in Luci (4f57), so it is computed in a different way, maybe what I read elsewhere that it's a hash of the SSID is correct. The values are consistent across all 3 APs though, so that's good.

The logs show WPA: FT authentication already completed - do not start 4-way handshake so I think it's working, at least for some clients (1 iPad so far).

Using the WiFiAnalyzer app on Android I can see WPA2-PSK+FT and RSN-PSK+FT for security, though this particular client does not seem to roam. Not sure at what signal strength clients decide to roam, I haven't seen this one lower than -70dBm.

In general the problem I have with the clients is that they see good signal strength from the AP but they can't reliably "yell" back at the AP (based on the numbers shown on the AP side, the clients have poor signal strength). The answer here might be to reduce the power of the "main" AP a bit to force clients to roam.

#8

For client support list on 802.11r you can check their website, as far as I know, iPhone4 and newer, Galaxy S4 and never supports 802.11r.

For roaming, between same freq. APs, client gets to choose based on their wifi score algorithm, again you can check this up on manufacturer website of the device. But for roaming between different freq. on the same AP, you can force client to steer/move by sending bss_tm request using hostapd_cli. You have to on snapshot build though.

You don't need to reduce power or do other bad tricks with OpenWrt. My advice will only run on one AP device, but you have several, therefore you can at least try and use DAWN package (didn't work for me) and read the forum about rrm, 802.11v, 802.11k which should do what you need.

#9

Good to do a survey of your environment and compare that to what parameters the clients like (for imitating a roam). I found turning AP transmit power down a hair was helpful to encourage roaming (my Apple devices roam at -70dBm). Clients ultimately are in charge of roaming. Try the latest dawn package and adjust your transmit power if needed (client devices are weak, best to not just think about the AP) for your environment to find your sweetspot. :sunglasses:

1 Like
#10

Any up to date guide on how to install and configure DAWN?

#11

His readme has a run down on his different parameters:

This is what the default dawn.config file has in it:

This is my config (the default + turned on HT, VHT, and turned on the 4x 802.11k options). @PolynomialDivision might have some better recommendations on what parameters to toggle.


root@OpenWrt:~# cat /etc/config/dawn

config network
        option broadcast_ip '10.0.0.255'
        option broadcast_port '1025'
        option tcp_port '1026'
        option network_option '2'
        option shared_key 'Niiiiiiiiiiiiiik'
        option iv 'Niiiiiiiiiiiiiik'
        option use_symm_enc '1'
        option collision_domain '-1'
        option bandwidth '-1'

config ordering
        option sort_order 'cbfs'

config hostapd
        option hostapd_dir '/var/run/hostapd'

config times
        option update_client '10'
        option denied_req_threshold '30'
        option remove_client '15'
        option remove_probe '30'
        option remove_ap '460'
        option update_hostapd '10'
        option update_tcp_con '10'
        option update_chan_util '5'
        option update_beacon_reports '20'

config metric
        option ap_weight '0'
        option no_ht_support '0'
        option no_vht_support '0'
        option rssi '10'
        option low_rssi '-500'
        option freq '100'
        option chan_util '0'
        option max_chan_util '-500'
        option rssi_val '-60'
        option low_rssi_val '-80'
        option chan_util_val '140'
        option max_chan_util_val '170'
        option bandwidth_threshold '6'
        option use_station_count '1'
        option max_station_diff '1'
        option deny_auth_reason '1'
        option deny_assoc_reason '17'
        option use_driver_recog '1'
        option min_number_to_kick '3'
        option chan_util_avg_period '3'
        option set_hostapd_nr '1'
        option op_class '0'
        option duration '0'
        option mode '0'
        option scan_channel '0'
        option ht_support '10'
        option vht_support '100'
        option eval_probe_req '1'
        option eval_auth_req '1'
        option eval_assoc_req '1'
        option min_probe_count '2'
1 Like
#12

Some people have issues with option update_beacon_reports '20'.
This values send every 20s beacon report requests to the client. Since I do not compare the reported values, u can just turn it off or set it to a higher value. Some person in the forum said, that I can extract rssi values from beacon reports. But the person just did not say how I can accomplish that.

If u want to test the steering with 802.11k I can just write a patch for you. But I need to know if the client device is reporting RCPI or RSNI values. U can see this in the hearing map.

Right now, I just use dawn to monitor my network.

There was an issue in my network that a client was forced to roam to another AP

disconnect from AP 30:b5:c2:6e:a3:7d for new auth to 60:e3:27:fb:4e:a5

and then I got a

wlp4s0: 60:e3:27:fb:4e:a5 denied authentication (status 1)

I have to debug this. Sadly, this is very bad status code since it means unspecified failure. -.-

@Xtreme512 I had a bug in parsing the nr-strings. That is why a steering to another AP was probably buggy with bss_tm request.

@ACwifidude and @ACwifidude
If u want to test and ur device responds to 802.11k beacon requests, I can just rewrite a code snippet.

#13

@PolynomialDivision My use case is maybe simpler. I only care about the 5GHz radio. I have 2 SSIDs on 2 VLANs (the typical home+guest setup). There is AP signal overlap and from what I call the "main" AP (R7800) where the secondary APs (UniFi AC Lite but running master OpenWRT ath79) are the signal from the client perspective is still OK around -70dBm. The problem I have is 2 Chromebooks that can't reliably talk back to the main AP, but they also don't want to roam, unless I manually disconnect and reconnect them when their are close to the secondary APs. I'd like to avoid reducing the main AP power as it covers another area where I'd lose reach.
What's the best thing to do here? Can DAWN monitor the signal from each client and when it gets to something like -68dBm tell the client to look for a different AP? I don't care much what happens when I walk with the Chromebooks, but eventually they get close to an AP and stay there for a while, so I'd like them to connect to the closest AP in that case.

#14

U could look into the wpad config and see if they are allowd to background scan.
DAWN monitors the rssi of them, but there is a huge issue that I don't blindly kick clients (if u want me to do, I can try). I make a map of the client (hearingmap) with APs the client can reach. For that the client needs to scan.

But now I added a patch, that the clients are peridically "forced" to report other APs signal strength to the AP back and if signal strength is good, I force them to roam.

@ACwifidude, @Xtreme512


Please read the commit message if u want to test. (it is untested, but when I'm home I will try that, too).
#15

Actually, u can install dawn and luci-app-dawn and look in the hearing map section.
If the chrome-books are not "probe-randomization-scanning", you can see what happens and if they scan.
Further, since I enable 802.11v, it could be that they roam more often if signal strength is weak.

I think @Xtreme512 wrote a script where he "blindly" bss-tm-kicks client based on the fact that he has only 1 AP and if the 2.4 GHz signal strength is good enough, he knows directly that the signal strength in 5 GHz will be good. You could probably do the same.

#16

Oh, I set the rrm-nr 802.11v strings wrong in the hostapd, if u have more than 1 SSID. I have to fix that. Not sure what happens if u have a nr-string that is not part of your ssid. If u want to try, maybe u could just switch off the guest wifi, until I release a fix.

#17

Thanks. I will wait a bit until you address this issue. Guest is more like work network, I don't want work/school managed devices on my private network, who knows what they push or monitor.

Also, not sure whether it matters for DAWN, but the APs can only talk to each other on the home VLAN, on the guest/work VLAN there is device isolation, the APs themselves don't even have IP addresses on that VLAN and there is no routing allowed between the 2 VLANs.

#18

I may test it again if your fixes come to software update in OpenWrt for me to install. I will keep it if it steers and also convinces client to stay without disconnection/interruptions.

#19

Looks like it isn’t reporting the rcpi or rsni (apple iOS client if that helps). I only use 5ghz for roaming devices and one SSID. I have all newer apple clients - all support r,v,k. I’d love to try out the k features once you think it is ready. The explanation on your proposed merge makes sense. Looking forward to it.


root@OpenWrt:~# ubus call dawn get_hearing_map
{
        "*******": {
                "**********": {
                        "********": {
                                "signal": -83,
                                "rcpi": -1,
                                "rsni": -1,
                                "freq": 5180,
                                "ht_capabilities": true,                                "vht_capabilities": true,
                                "channel_utilization": 0,
                                "num_sta": 3,
                                "ht_support": true,
                                "vht_support": true,
                                "score": -2
                        }
#20

Do u have full-wpad installed?