Finally got 802.11v working (FULLY) - Few pointers

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. :slight_smile:

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. :sunglasses:

Sry, I'm currently very busy. Next week I have time to fix everything! :slight_smile:

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: (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...

1 Like

There's some potentially useful looking code in here for understanding the quality information: 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:

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.

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-

  1. Turn your 802.11r on (just click the toggle on the luci GUI)

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

  1. go to software on your luci GUI, click the “update lists...” button.

  2. search for dawn in the filter box

  3. install the dawn and luci-app-dawn

  4. 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?

1 Like

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?

It should support my hardware.

Can the rssi levels be configured for switing ap with 802.11v

This commit is not included:;a=commit;h=c8ef465e10f46fd017cc9c3e455cc368a2b9da2b

Which version is that commit included in?

Master has it, 19.07 doesn’t. Use master to try out 802.11k and v. :sunglasses:

It isn’t required. It adds a nice GUI representation of your network and an easy way to configure all the options.