Finally got 802.11v working (FULLY) - Few pointers

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:

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

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


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.


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.


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.

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

Currenty only mips_24kc.

1 Like

Stuff happend.
I got a PR that is updaing my luci app. :slight_smile:
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.


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

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?

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    

@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

1 Like

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

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

1 Like

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.

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

You need:

  • latest openwrt master branch

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.

1 Like

The legacy DAWN version does not work with mac randomization.

One important step:

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. :confused: Okay, I need definitely 802.11k...

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?

do we have a guide on how to config the router to configure a band steering between 2.4 ghz and 5 ghz on the same router?

You can look @anom3 GitHub

I have two R7800:

  • router with 2.4 GHz guest and 5 GHz main network and
  • access point with 5 GHz main network only

While Android client is seeing AP with medium signal strength and router with weak signal it is being switched back and forth between those two until after a few switch-overs is loosing association for a few seconds altogether.
Is there a way to make it stick to stronger signal?
Also, not sure if that is related, AP is showing all the time in Network Overview table all networks but router most of the time is listing only own networks.
Any suggestions?
BTW I left all the DAWN settings with default values.

Please look if you are able to find the other routers with

ubus call umdns hosts

Sometimes I have to change my umdns config /etc/config/umdns and add ẁan.

onfig umdns
        option jail 1
        list network lan
        list network wan

You have the ability to change two rssi values:

rssi_val is the lower bound for an "good" rssi.
low_rssi_val is the lower bound for an acceptable rssi.

That is all that hearing map stuff, that is very problematic. :confused:
You need to get an up-to-date RSSI. And that is why I will implement 802.11k and will drop hearing maps with probe requests.
I would change the values.
Very important: The configs have to be the same on all routers!
You can look in the Hearing-Map Section, which score an AP has for which client. If the score is negative something is very bad (like very low rssi).

Here are some related issue:

1 Like