Finally got 802.11v working (FULLY) - Few pointers

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

If u left all settings with default, load balancing is currently not activated?

The settings are here:

Maybe you should look here:

And disable use_station_count. Maybe something is calculated wrong.
Is this line correct?

Maybe just wait until 802.11k is implemented.

Adding wan to umdns config let each R7800 see one another. As a result also pace of switching between APs is lower.
Reduced rssi_val to -80 and low_rssi_val to -100 but not sure there is an improvement. Not even sure if those values make sense :slight_smile:.


I implemented 802.11k but I have several problems:

  • How to compare RCPI, RSNI, RSSI?
  • Strange behavior in 5 GHz (beacon report requests are just ignored if they are send from 5 GHz radio)

Otherwise, it works. :wink:

I tested your scripts and I'm having problems with my Samsung S8 as client. It keeps disconnecting after a few seconds even while not sleeping and when it sleeps it reverts to LTE and never reconnects to wifi.

I can get the neighbor report and can steer clients manually so I guess it may be something related to my mobile phone that's somehow not compatible with the script. You said you had the same problem if hostapd-cli is used too frequently but I could not figure out how to modify your code to troubleshoot the problem (I'm not a coding expert, particularly php).

Very nice work nevertheless!

What version of OpenWRT are you running?

Not sure how fluent you are in PHP but its pretty simple, where ever you see the commands to force a roam compare them to the commands that work...

When ever I had that issue it was because either A) the abridged parameter was not present, or B) I was trying to force a roam to a non-existent OR incorrectly entered AP. Make sure your neighbor reports are 100% correct and the mac addresses are too. Macs in the config file should all be lower case.


RCPI / RSNI / RSSI : Good question! I have no idea... I spent about 1 hour googling but I ran out of time... For the time being I use strictly RSSI... 99% of the time its fine. In my setup I can do this because my 5ghz APs (and others) are so close that there is quite a bit of overlap... And worst case I bounce back and forth between APs a bit as I move around... I found that even things like Skype don't mind and there is no lag / stalls.

Becaons @ 5GHZ : Does hostapd report ack=1 for the beacon request at all? If it shows ack=1, then it was received by the client... Usually when I had problems with not getting back beacon reports when I should be able to get one back it was because of the "scan type" + "scan duration" + "scan randomization interval". EDIT : I should note that I set my APs to beacon interval @ 50... Not sure if this helps, but the logic was... More beacons, short scan durations = higher chance to picking up a beacon.... EDIT 2: I'm sure you know, but make sure your "op class", "phy type" and "channel" are all correct in the beacon request...

WARNING, I know nothing, I'm guessing here, but it does work:

For me what I found worked 99.9999% of the time was:

Scan type = Active (01)

Scan duration = 25-35 (converted dec to hex) - Could never figure this out fully... I checked the hostapd source... 2 x 2byte... but no matter what combo I tried, going up from (lets say) 100 (guessing? ms?) it would not make any difference. All the 802.11 documentation I read said this is "time units"...

Randomization interval = 0000 (hex)

Here is a snippet from the code I use... 25-30 btw... I use this because it gets returned back in the beacon response. So using this I am able to double check that the response is actually for the beacon request I am waiting for.

// duration *** still have not figured this out fully, but i am using this to identify the beacon request ***
// mode [ 0 = passive, 1 = active, 2 = table ]

Note, you are now reaching the part where I was not able to figure things out fully... Let me know if you can figure out how to get a proper RSSI with noise accounted for OR how to set an actual scan duration in the beacon request OR what "randomization interval" does.

1 Like