802.11k Neighbor report daemon

Community Builds, Projects & Packages
#1

The 802.11k standard specifies how the neighboring BSS' could report each other to a STA. OpenWRT's hostapd supports this feature, but the synchronization has to be done in a separate daemon such as this one.

It is more lightweight than DAWN (many thanks to Polynomdivision), basically it is based on this script How does rrm work? - #60 by ParanoidZoid although it is improved a bit so the neighbor report would include the other band interface for the same AP and some more fixes.

Tested on 20.02rc2 with 22 different AC1750. Using 802.11r configured roam over the air, and disabled the bss transition bit on the network it works like a charm. Walking with my 2,4GHz only phone wifiman show roaming well. My Arch based dual band laptop works even better. Cannot even notice that walking along the corridor my BSS changes nearly every second step.

I've plans to make a package from it and make it published as an ipk. I'll also add a sample config file for /etc/config/wireless so the whole test setup could be reconstructed.

Update: I've missed the github link: https://github.com/simonyiszk/openwrt-rrm-nr-distributor

5 Likes
Band steering feature status
#2

This is pretty awesome, thanks!

I have it running across 4 AP's and it seems to handle the transition pretty smoothly. I noticed your repo lacks a sample wireless config, so I'm pasting the relevant bits from mine should anyone else want to give this a go.

For starters, each AP is configured as a "Dumb AP" according to the docs. I have also installed the following:

wpad-wolfssl
umdns
libseccomp
scmp_sys_resolver
iwinfo

To get umdns working, I configured /etc/config/umdns for my network:

config umdns
  option jail 1
  list network lan

I also had to comment out the seccomp line in /etc/init.d/umdns as described here.

For /etc/config/wireless, I set up 802.11r by adding the below to the wifi-iface section for my SSID:

option ieee80311r ‘1’
option ft_over_ds ‘0'
option ft_psk_generate_local ‘1’

I then set up 802.11k and 802.11v (steering) as follows:

option ieee80211k '1'
option ieee80211v '1'
option wnm_sleep_mode '1'
option bss_transition '0'
option time_advertisement '2'
option time_zone 'CST+6CDT,M3.2.0/2,M11.1.0/2'

My time zone is explicitly specified so as to appear in the beacons although I've read in some threads this isn't necessary and would be handled automatically by hostapd. For that matter, I've read that 802.11v isn't required anymore either, but I've left it in anyway.

I've also disabled bss_transition and set FT to over-the-air as you indicated in your README.

Finally, I copied your rrm_nr scripts and started them up. This was running the latest rc4 of the 21.02 release.

This appears to be working, but aside from seeing FT skipping the handshake in the logs and my client roaming from one AP to the other as I walk about the space, I haven't done much else to prove it's working as designed.

2 Likes
#3

Your seems to be right. I've updated the repo with my config file. (I've just recognized that the nasid is the same for the 2.4 GHz and the 5 GHz radio. I'm a bit uncertain if its good this way.)

Fixing umdns startap's seccomp section is also an issue in my devices.

As far as I know bss_transition should be disabled, since this package doesn't actively suggest roaming for the STAs.

For testing you can try ubus call hostapd.wlan0 rrm_nr_list. If it shows your other BSSes, than the daemon is working. You could try wifiman from Ubiquiti for eg. to test this on your android STA. Just connect to your AP at 2.4 GHz, and if the 5 GHz shows up immediately in the BSS list for the SSID, everything is okay. Getting the traffic with a laptop in monitoring mode and wireshark could also show what is in the air. The edge of this project is hostapd's nr_list. Capturing management traffic from the AP itself should also work.

1 Like