Finally got 802.11v working (FULLY) - Few pointers

PolynomialDivision · May 9, 2020, 10:44am

You can subscribte to hostapd. I added a PR that decodes those binary blobs:

https://github.com/openwrt/openwrt/pull/2597

Another important part

https://github.com/openwrt/openwrt/pull/2856

Further Threads:

How does rrm work? - #61 by PolynomialDivision

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

https://polynomialdivision.github.io/openwrt/2019/05/05/clientsteering.html

And the GSOC Stuff

https://blog.freifunk.net/author/nickgsocgmail-com/

Interesting. I have to look how I can scale DAWN to that level. But maybe this requires a more centralized version.

IanC · May 9, 2020, 10:56am

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

PolynomialDivision · May 9, 2020, 11:03am

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.

IanC · May 9, 2020, 11:38am

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.

ACwifidude · May 10, 2020, 1:09am

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:

github.com

openwrt/luci/blob/master/applications/luci-app-dawn/luasrc/model/cbi/dawn/dawn_config.lua

m = Map("dawn", translate("Dawn Configuration"), translate(""))
s = m:section(TypedSection, "metric", "Metric", "Metric"); s.anonymous = true;
s:option(Value, "ht_support", "High Throughput Support")
s:option(Value, "no_ht_support", "No High Throughput Support")
s:option(Value, "vht_support", "Very High Throughput Support")
s:option(Value, "no_vht_support", "No Very High Throughput Support")
s:option(Value, "rssi", "RSSI")
s:option(Value, "low_rssi", "Low RSSI")
s:option(Value, "freq", "5GHz")
s:option(Value, "chan_util", "Channel Utilization")
s:option(Value, "max_chan_util", "Above Maximum Channel Utilization")

s = m:section(TypedSection, "metric", "Threshold", "Thresholds"); s.anonymous = true;
s:option(Value, "bandwidth_threshold", "Bandwidth Threshold")
s:option(Value, "rssi_val", "RSSI Threshold")
s:option(Value, "low_rssi_val", "Low RSSI Threshold")
s:option(Value, "chan_util_val", "Channel Utilization Threshold")
s:option(Value, "max_chan_util_val", "Maximaum Channel Utilization Threshold")
s:option(Value, "min_probe_count", "Minimum Probe Count")
s:option(Value, "min_number_to_kick", "Minimum Number After Kicking Client")

This file has been truncated. show original

IanC · May 11, 2020, 7:46am

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?

ACwifidude · May 11, 2020, 8:03pm

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.

PolynomialDivision · May 11, 2020, 8:33pm

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.

IanC · May 11, 2020, 9:00pm

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

IanC · May 12, 2020, 7:46am

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.

pauljbl · May 18, 2020, 4:04pm

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?

ACwifidude · May 19, 2020, 2:25am

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.

hoangminh88 · May 19, 2020, 6:56am

Do need install luci-app-dawn?

pauljbl · May 19, 2020, 9:33am

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?

ACwifidude:

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.

ACwifidude · May 19, 2020, 12:37pm

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?

https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=refs%2Fheads%2Fopenwrt-19.07&st=commit&s=802.11k

https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=refs%2Fheads%2Fopenwrt-19.07&st=commit&s=802.11v

pauljbl · May 19, 2020, 1:53pm

It should support my hardware.

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

PolynomialDivision · May 19, 2020, 2:45pm

This commit is not included: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8ef465e10f46fd017cc9c3e455cc368a2b9da2b

pauljbl · May 19, 2020, 3:03pm

Which version is that commit included in?

ACwifidude · May 19, 2020, 10:15pm

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

ACwifidude · May 20, 2020, 12:15pm

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