Finally got 802.11v working (FULLY) - Few pointers

anom3 · March 13, 2020, 1:21pm

Just a short update... I have it working pretty much flawlessly.

To make it work 100% one needs to use req_beacon (hostapd_cli, there is a ubus hook for it though), mode 1, and it will send back a beacon report to the AP.

Once you have captured the beacon report and fed it back into your infinite loop script, you can act based on that and send out a BSS-TM request if necessary.

Note : This works quite a bit better on QCM based adapters... On my mediatek based repeater on my middle floor, it would roam to or from it no problem, but there was always a bit of a pause during authentication (even with 802.11r)... I had a mediatek based RE650 there, but had an older RE450 in the drawer which is QCM based... So I swapped it out and its flawless.

Essentially you need to have 2 scripts:

A) One that receives the beacon report, executed via hostapd_cli -a SCRIPTNAME. Save the beacon report somewhere, I chose in /tmp.

B) The main script which besides sending out BSS-TM requests when you deem necessary, but also sends OUT the beacon report requests and waits for a response (in my case, to be saved into /tmp/....).

Yeah its complex, but once its all together not that bad...

Once its all polished I will put my script up on github with a quick wiki how it works.

And finally here is the log of 3 of my APs working together as I go from upstairs to down stairs and back up.

FLOOR GROUND:

2020-03-13 13:55:51 | Sent AP-STA-CONNECTED [My S7 Edge MAC] wlan0 events
2020-03-13 13:56:14 | Candidate [Middle floor AP MAC] has rssi of 59, forced roam via hostapd_cli -i wlan0 bss_tm_req [My S7 Edge MAC] neighbor=[Middle floor AP MAC],0x0000,128,36,9 pref=1 abridged=1 2>&1 [OK]

FLOOR MIDDLE:

2020-03-13 13:55:42 | Sent AP-STA-CONNECTED [My S7 Edge MAC] wlan0 events
2020-03-13 13:55:51 | Candidate [Ground floor AP MAC] has rssi of 59, forced roam via hostapd_cli -i wlan0 bss_tm_req [My S7 Edge MAC] neighbor=[Ground floor AP MAC],0x0000,128,36,9 pref=1 abridged=1 2>&1 [OK]
2020-03-13 13:56:15 | Sent AP-STA-CONNECTED [My S7 Edge MAC] wlan0 events
2020-03-13 13:56:28 | Candidate [Upstairs floor AP MAC] has rssi of 63, forced roam via hostapd_cli -i wlan0 bss_tm_req [My S7 Edge MAC] neighbor=[Upstairs floor AP MAC],0x0000,128,36,9 pref=1 abridged=1 2>&1 [OK]

FLOOR UPSTAIRS:

2020-03-13 13:55:41 | Candidate [Middle floor AP MAC] has rssi of 65, forced roam via hostapd_cli -i wlan1 bss_tm_req [My S7 Edge MAC] neighbor=[Middle floor AP MAC],0x0000,128,36,9 pref=1 abridged=1 2>&1 [OK]

Final note, at least with my S7 Edge... The beacon report responses are pretty much instant. Even when scanning the opposite frequency... They are 'live' as well... I'm sure this is horrible for battery life, but I have it set up so it only sends out the beacon requests when the RSSI reported by iw dev wlanX station get is low enough to warrant a roam. Which, when the screen is on anyways, is updated every xxx ms, so it is fairly fresh.

So there it is, 802.11v band steering / assisted roaming, 100% working on 2xOpenWRT + 1xDebian (errr... hostapd to be quite honest...)...

zeldi · March 22, 2020, 3:53pm

Congrats for the working environment!
I am looking for the same solution. Have you managed to publish the scripts on github?

Looking forward.

LGA1150 · March 22, 2020, 4:38pm

@PolynomialDivision ping

PolynomialDivision · March 22, 2020, 5:36pm

@LGA1150 Thanks for pointing me to this thread.

Since, I have to stay at home, I just began to go further with the stuff I already did.

Please, up-vote my PR.

Further, I wrote DAWN. And now I start to work on this issue. So I just fix and refactor my daemon to get things into official openwrt repository.

On some branch, I already exchanged neighbor reports automatically, and implemented bss transition. I will go on with it, after bringing the legacy version into the package tree.

anom3 · March 23, 2020, 12:36am

Hi all, I will post my script in a short while (2-3 days).

A couple of notes, just so everyone is clear.

A) Its written in PHP. I am most fluent and things just go quickly for me in PHP so I chose PHP. I know its not optimal for OpenWRT but someone can port it fairly easily if they desire. Knowing I would be sharing it I have commented it heavily.

B) My script is sort of tailored to my setup here at home, although the important settings are fed via a config file.

As previously mentioned, but I will mention again:

I live in a 3 floor home that is concrete.
Each floor has an dual band AP that is wired via ethernet to a switch downstairs.

What does this mean? That on each floor, I have a good strong 5ghz signal from that floors AP.

So the name of the game is fairly straight forward:

If the client device has a strong RSSI at 2ghz, then roam to 5ghz via BSS-TM ASAP. This will happen quickly, under 1 second after a strong RSSI is detected.
When the 5ghz signal starts to drop below a set value (-65 dbi is what I use for this), start sending out beacon requests and see if we can roam to a 5ghz AP on a different floor. Once the connected to AP is at -70dbm, but another candidate has a better signal, roam over to the stronger AP. This works in my case because even at 5ghz there is always some overlap with my 5ghz access points.

This works very well, about 99% of the time my script will steer the device as I am walking. I am able to have skype video conversations jumping between APs with zero cut outs or lag or stalls. The only time it doesn't work is if the client device is more aggressive in the roaming then my script.

I have 2 spots in my home where sitting on 2ghz is optimal. I leave that to the client to decide on its own. On my patio and terrace upstairs I just let the phone roam on its own from 5ghz to 2ghz there.

C) Initially I had this all setup so that even when the screen was off on the mobile device it would steer the roaming. It is possible to keep the wifi adapter awake on my S7 Edge (probably most Android devices) by sending a pool request. In the end I opted not to do this. No point in wasting my battery. I check if the device has the screen on AND is actively using wifi by checking the inactive field in the

iw dev wlanX station get CLIENTMAC

dump. If its over 1 second, I skip the loop and check again, until its under 1 second.

D) NOTE : This works best with Qualcomm based (ath9k / ath10k) adapters. As mentioned somewhere above I have a Mediatek based RE650 as well... It appears that the chipset in that device (all mt based devices?) does NOT bridge the wireless and ethernet ports correctly and the broadcast packets are dropped / somehow not handled fully on roam. I am unsure as to the cause / solution to this as I just swapped it out for my Qualcomm based RE450 and off I went.

E) Of course you will also want to setup 802.11r to make the auths quicker. In my case 802.11r works even between bands (2.4 <-> 5.8). While you are doing it might as well get 802.11k done as well for the times you want the device to roam on its own.

Will post in a couple days when its up on github.

PolynomialDivision · March 23, 2020, 6:48pm

Okay, I made a PR.
I will add the luci-app-dawn after the controller is accepted, cause I did a workaround to have that in a sepertaed feed.

Maybe I just upload some ipkg to github.

anom3 · March 24, 2020, 3:03pm

Alright, I have posted what I use on github.

Like I said, its not perfect but for my use case it works great. I documented as much as I had time to, heavily commented it and assuming you have a fairly standard setup on OpenWRT, you should be able to get it up and running.

anom3 · March 24, 2020, 7:28pm

When initially documenting things I was rushing, so there were a few (small) errors here and there. I had a few minutes now to clean it up so it should be a little more clear.

PolynomialDivision · March 24, 2020, 9:02pm

I packed my daemon.
Install instructions to add my feed into opkg:

Currenty only mips_24kc.

PolynomialDivision · March 25, 2020, 12:32am

Stuff happend.
I got a PR that is updaing my luci app.
Looks nice!

I updated the opkg package feed with the newest luci and dawn version.
So opkg remove luci-app-dawn and then opkg update and okpg install luci-app-dawn, to upgrade only the luci app.

Further @anom3 gave me an important advice to improve 802.11v which I used to make a new PR:

And I created the already mentioned opkg package tree.

mooninite · April 2, 2020, 12:54pm

I see that both dawn and luci-app-dawn are merged. When will they be available in the 19.07 repo?

PolynomialDivision · April 4, 2020, 9:25am

For that, someone would need to backport the stuff to 19.07?
The current version should run on 19.07 without any problems. But future versions will require the changes in the hostapd ubus interface, that I linked and are now official merged.

Why do u need dawn in 19.07? Won't 19.07 be in near future legacy, because of shorter release circle?

ACwifidude · April 4, 2020, 6:52pm

How is 802.11v working now that it is merged?

Here is my current configuration for both my r7800 APs on the latest master build (other AP is on a different channel, everything else is the same):


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

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option txpower '22'
        option legacy_rates '0'
        option country 'US'
        option beacon_int '67'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ft_over_ds '1'
        option ssid '********'
        option ft_psk_generate_local '1'
        option key '********'
        option ieee80211r '1'
        option encryption 'psk2+ccmp'

I have iOS devices that support r,k,v. As a client iOS devices start roaming at -70 dBm. To get v working is it as easy as adding the below options to the wireless config? Anything further to get the party started (sorry, I know this is a dumb question but just trying to consolidate the rrm and this thread’s notes to get up and running). Is there anything further that has be tweaked?


uci set wireless.default_radio0.ieee80211v=1; uci set wireless.default_radio0.ieee80211k=1; uci set wireless.default_radio0.bss_transition=1; uci commit

anon50098793 · April 5, 2020, 1:12am

@PolynomialDivision... selecting dawn in luci on current master selects umdns... i'm getting a compile error on that;

umdns interface.c unrecognized command line option -Wno-address-of-packed-member

[ 11%] Building C object CMakeFiles/umdns.dir/interface.c.o
/fs/sdd1/openwrt/RTNGext/vanillamaster/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/umdns-2018-01-02-78974417/interface.c: In function 'read_socket4':
/fs/sdd1/openwrt/RTNGext/vanillamaster/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/umdns-2018-01-02-78974417/interface.c:193:10: warning: variable 'ttl' set but not used [-Wunused-but-set-variable]
  uint8_t ttl = 0;
          ^~~
/fs/sdd1/openwrt/RTNGext/vanillamaster/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/umdns-2018-01-02-78974417/interface.c: In function 'read_socket6':
/fs/sdd1/openwrt/RTNGext/vanillamaster/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/umdns-2018-01-02-78974417/interface.c:267:6: warning: variable 'ttl' set but not used [-Wunused-but-set-variable]
  int ttl = 0;
      ^~~
/fs/sdd1/openwrt/RTNGext/vanillamaster/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/umdns-2018-01-02-78974417/interface.c: At top level:
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' [-Werror]
cc1: all warnings being treated as errors
CMakeFiles/umdns.dir/build.make:153: recipe for target 'CMakeFiles/umdns.dir/interface.c.o' failed
make[6]: *** [CMakeFiles/umdns.dir/interface.c.o] Error 1

( just fyi ) peace

PolynomialDivision · April 5, 2020, 7:20am

I've submitted a patch on the mailing list that is fixing the umdns problem.

@anon50098793: Please Pull and try rebuilding. The patch is now included.

PolynomialDivision · April 5, 2020, 7:27am

You need some control logic, that makes use of 802.11v. Or the client can request neighboring reports from APs. There are different use cases.

For controlling clients you can look at:

Further, I'm adding 802.11v functionality to my controller dawn.

Otherwise you can find here: How does rrm work?
how to populate the Neighboring AP Lists of all APs in your homenetwork, so a client can request possible roaming canidates via 802.11v.

PolynomialDivision · April 6, 2020, 5:01pm

If someone wants to test with me, I implemented bss transitions (802.11v) in the branch feature/80211v.

You need:

latest openwrt master branch

anom3 · April 7, 2020, 10:31am

Just a quick note... With the (very - 2 days old) recent changes to MT7621 (kernel bump to 5.4), roaming has improved quite a bit on MT76 chipsets.

Looks like its because of the DTS based bridging (rather then swconfig etc).

I have been able to put my RE650 back in and am now getting nice fast roaming when roaming to the MT7621 based AP.

PolynomialDivision · April 7, 2020, 5:20pm

The legacy DAWN version does not work with mac randomization.

One important step: https://wiki.archlinux.org/index.php/NetworkManager#Configuring_MAC_address_randomization

Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to /etc/NetworkManager/NetworkManager.conf or a dedicated configuration file under /etc/NetworkManager/conf.d

You have to disable it. Okay, I need definitely 802.11k...

PolynomialDivision · April 7, 2020, 5:39pm

@anonm3
I definitely need 802.11k, but can u give me some information what the best parameters for beacon requests are? And what can I do to force a client to scan the whole frequency spectrum?