Interesting. I don’t have that error, is it a particular client causing the issue or is it a difference in network design?
r7800 Router
(no wifi, dawn installed, no adjustments to umdns)
| \
| eth eth \
| \
r7800 AP r7800 AP
Separate 5ghz SSID and 2.4ghz SSID, different channels
(dawn installed and wan added to umdns for both)
Please change that value to a much higher one, e.g. 360 or set it to 0, this will disable beacon reports. Then the message should go away. 
Further, it would be nice, if you could debug that with umdns, if the mdns entrys are existing and the APs are seeing each other.
Dawn looks really nice. Still waiting for my 2nd access point to arrive to try it.
Does anyone know if 802.11r works well in mixed wifi vendor environments with openwrt?
E.g having a router with an aetheros chipset and a mediatek wifi one?
My 2 cents (I am not using DAWN at the moment). In my scenario, 802.11r works perfectly in an environment with WR841 (ath79) and Archer C2 - v1 (mediatek).
When the configuration is the same, no problems should arise at all.
Hi @PolynomialDivision and others
A week or so ago I started looking at how to use the 802.11k+v features to help steer various devices around the house to the AP that can best support them at any given time. I thought I was going to write a few scripts to aggregate the current station / client status, process that on my most powerful AP (others are simple 4+32 devices) to look for "outliers" and then tell relevant APs what disassoc frames to send.
Every time I reach the next step I find myself back at this thread which seems to be the main resource for understanding various elements: neighbor report gathering and sharing, beacon requests, using hostapd to gather them, etc. My next step was to untangle the beacon report binary blob that hostapd dumps into the logs. And when I look for guidance on the structures used it brings me here again :)!
So it's looking like the best way forwards for me for now is to get DAWN up and running and see how close what it does is to what I want, and maybe contribute some changes if we have slightly different goals that can use the same lower level capabilities. For example, I can imagine that some will want to optimise use and stability of tens - hundreds APs in a large site, while others (like me :)) are more interested in client experience across a few lightly loaded APs.
I'm newish to OpenWRT dev, but have ported a few new devices (that are very similar to existing ones) into my local builds, backported packages to similar, etc. I'm a decent C coder having started my career working (perhaps ironically) on early comms infrastructure management. If I get things up and running let me know what ic an do to help nudge things forwards.
You can subscribte to hostapd. I added a PR that decodes those binary blobs:
Another important part
Further Threads:
And here is some blogpost of mine (with a lot of grammar mistakes... I think I have to update the blogpost when I have time...):
And the GSOC Stuff
Interesting. I have to look how I can scale DAWN to that level. But maybe this requires a more centralized version.
Yep, that RRM thread was very useful as well :). And I saw the hostapd-cli / subscription pieces and PRs. Basically all a part of the journey I was / am on.
I see the balance of AP vs client decision making as perhaps some form of top level policy: "AP loading", "client experience", "blended" that we could develop. We won't need lots of real APs - we can simulate that for the algorithms if needed. It'd be interesting to see if that can still be a distributed model for resilience and not creating too much management traffic going back to a central point - which would be ironic.
Thanks for the PM. I'll be in touch. Busy now...
You can drop a lot of information with 802.11v and 802.11k and make the stuff "on-demand". All that management traffic I'm currently exchanging is because of legacy clients... If I switch to 802.11v, I can immediately decrease the complexity.
I was thinking of the overhead of all APs sending information back to a central decision making node in the 100s of AP case. It'd be silly if so much information was flying back and forwards that it was slowing things down. I don't think it would be so bad, but there are still reasons to think about a distributed model where you can just turn on 20-100 devices pre-configured to know about each other via (say) MAC address and let them self-organise for the target outcome.
It would be interesting to have different toggles in the dawn luci app to be able to turn on and off sections of the code. This would make your code a little more complicated but would be interesting.
As an example I have no legacy hardware on either band and no roaming devices on 2.4ghz - so I would toggle off all the legacy compatibility + 2.4 ghz mapping to optimize the setup for the best performance.
I could help with the luci page coding and descriptions if you’re interested:
I've added DAWN to the flashed in packages for my local builds. I'll play with it a bit to understand what it does and perhaps look over the code to help me. I have a few busy days ahead, but will be back when I can be.
Is there another discussion of DAWN somewhere on what situations it aims to support, backlog requests, etc?
This thread is basically an extension of the rrm thread. This is the only dawn discussion thread. Several of us has been testing it- @PolynomialDivision is the contributor for dawn.
So far roaming is smooth between my APs. We’ve made recommendations for showing APs that don’t have any connected clients. Otherwise the 17 April version seems to be working well. 
Sry, I'm currently very busy. Next week I have time to fix everything!
There is a huge problem with global interface. Suddenly hostapd has this global interface. I will fix that soon.
I think this is the official definition of how RCPI should work: https://patents.google.com/patent/US8462701. (RCPI * 0.5) -110 is dBm power, but only within 5dB.
So if client is reporting (say) RCPI = 100 (-60dBm) the AP connected to it could easily be saying -50dB to -70dB RSSI due to the inaccuracy, and perhaps that one end is broadcasting more power than the other. I think that last effect would tend to make the AP RSSI lower (more negative dB) than (converted) device RCPI as AP will be broadcasting stronger signal.
That looks like it roughly fits the Samsung data above. No idea what Apple are doing though...
There's some potentially useful looking code in here for understanding the quality information: https://github.com/chunsj/nxctrl/blob/master/iw-test.c. It looks like there a three accepted usages of the RCPI / signal quality field which are indicated by a status bit.
With a quick look I can't make the Apple data fit any of them, although ~280 - the decimal value gets pretty close.
I found it by first of all thinking that LUCI must have a way to untangle the data. A search for "LUCI rcpi" led to the IW_QUAL_... definitions in here, with onward searches taking me to the above: https://github.com/ntlf9t/luci-1/blob/master/contrib/package/freifunk-watchdog/src/wireless.22.h.
I haven't had time to look, but am thinking there should be something reusable in libiwinfo (or new code that should live there) that does this.
Hi
I have a r7800 how would I go about making 802.11v and k work on openwrt. I don't know much about codeing.
What do I need to install and setup?
Super easy thanks to all the great work. I’m running hynman’s master build on a r7800.
This is how I got it running on my 5ghz radio, you’ll need to do this for each access point. You can do it for 2.4ghz too if you change the radio name in the below command-
Turn your 802.11r on (just click the toggle on the luci GUI)
Enable v & k (run this command in its entirety):
uci set wireless.default_radio0.ieee80211v=1; uci set wireless.default_radio0.ieee80211k=1; uci set wireless.default_radio0.bss_transition=1; uci commit
You can check that they were added by running:
cat /etc/config/wireless
go to software on your luci GUI, click the “update lists...” button.
search for dawn in the filter box
install the dawn and luci-app-dawn
refresh your browser page and enjoy the new dawn options. I’ve found its pretty good right out of the box.
Do need install luci-app-dawn?
Thanks for the reply
Do I need to be on a certain version of openwrt?
Are there any settings to make 802.11v switch aps at certain rssi levels?
19.07 seems to have the commits for 802.11k and 802.11v. Personally I use master branch on a r7800. @PolynomialDivision - any reason 19.07 or certain devices wouldn’t support your software?