What is the state of 802.11r, k, and v support in OpenWrt

I am curious how well openwrt is doing on 802.11k,r, and v in openwrt/linux these days?

two relevant links:

Refer to this thread

1) 802.11r

In it's current form, 802.11r is well-supported by OpenWrt (as long as the underlying WLAN driver/firmware can parse Mobility Domain Information Elements). It is practically 1-click config in LuCI for WPA2-PSK and as long as both APs have the same SSID. For me however, I need an additional step where I switch FT-over-DS to FT-over-Air because I get the following error with DS (maybe because I don't have a controller):

NL80211_ATTR_STA_VLAN failed: -2 (No such file or directory)

2) 802.11k

The switches to enable/disable are in mac80211.sh and thus can be enabled/disabled in the /etc/config/ folder. However, a script has to be used to be able to pull in the information required by hostapd to generate a neighbor report.

At least on ath10k(-ct) & ath9k, it works:

3) 802.11v

Whilst again, the switches exits in mac80211.sh and thus can be enabled/disabled in the /etc/config, there is no script/logic that fills in the required data. @PolynomialDivision is working on it through a de-centralized controller, DAWN for this (which now exists as a package in OpenWrt snapshots). But @anom3 has also built a set of scripts which also aims to do the same.

My experiences are limited to ath10k & ath9k. I know that mwlwifi does not support anything beyond 802.11r. I am unsure of the current state of support for anything else like brcm or mt76.


thank you very very very much for the update. I guess it still requires configuration primarily because of the problem of a rogue AP? What happens when two APs are on the same SSID but with different keys or crypto parameters?

I am not qualified to give an answer on this, but my guess is that it is a reason, but not the primary one. I think the main one is that no one just had the time to set it up as 802.11r was good enough for most people.

I have not tried this, but I believe that 802.11k and 802.11v would still work just fine. However, 802.11r may not work so well anymore esp. if the station only records one kind of crypto parameter/key.

Here is the software developed by @PolynomialDivision and others. It’s easy to install his dawn controller and dawn LuCI app from the OpenWRT software repo. My roaming is smooth with the defaults. Currently tinkering / testing to see what the different parameters do with 802.11k and 802.11v. Definitely worth a try. :sunglasses:

1 Like

Is there a step-by-step full manual on how to really enable 802.11v and .11k on OpenWrt?
Is it even supported on 19.07.3 stable release?
Does ath10k-ct(-htt) non-ct FW and drivers matter on this situation?

I just want to steer my client to 5GHz whenever the signal is good and use 2.4GHz when the signal is bad.

note: cant find dawn app on software page.

Here is the step by step. It should work fine on 19.07 - let me know if you have any issues.

Enjoy! :sunglasses:

I read the whole page and other few threads about it, not working on my end 19.07.3 stable. hostapd-ct, DAWN are not available. Therefore nothing is working, not even the anom3's comprehensive beautiful script.

I'm also interested in working on a set of steps for this. I've been trying Mesh devices such as the Deco products and just not impressed. Since I've got Ethernet back-haul I realized I should try getting this working on OpenWRT on my existing devices as it might fit the bill just fine.


We're actively working on DAWN to make it more scaleable and robust.

If you're using local builds, did you try "scripts/ feeds update && scripts/feeds install dawn" to add it to menuconfig (under Network)? I'm not sure what the status is for binary only distribution...


In my experience Dawn requires you to use the snapshot-branch, which ist more up to date than 19.07.3, on most of the devices if not all.

19.07 is missing a critical commit towards making dawn work last I checked (my above post is incorrect :see_no_evil:).

Dawn requires master. :sunglasses:

Im on master since last month and using a single command automation (bss_tm_req) for steering which DAWN couldnt even do in my testings. its sophisticated regarding all the hearing maps and other stuff, but cannot even steer a client basically.

1 Like

DAWN has vastly improved in the last month, I have it setup with 4 APs and my clients roam fine.
I didn't actually verify that DAWN is steering them though, so it doesn't contradict your findings just saying maybe you should re-test or give feedback in the DAWN github page so the devs can improve it


I install 802.11k/v/r and dawn on my 4 APs.. I'm noticing the following (many times) in my logs
daemon.err dawn[2040]: Neigbor-Report is NULL!

any pointers?

It is a known issue: https://github.com/berlin-open-wireless-lab/DAWN/issues/108

Do u see any values for rcpi or rsni that are not -1?

Thanks sent you screenshots of hearing map in github.. I can help you debug this if you wish..

rcpi and rsni are all -1.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.