Proper configuration of 802.11k and 802.11v

[Lynx]

So is it a fair assessment that without usteer or DAWN 802.21k and 802.11v will achieve nothing?

If so that would simplify things.

But see this:

Proper configuration of 802.11k and 802.11v

For 802.11k enabling option ieee80211k '1' enables reporting of things to the devices like channel utilization and how many clients are on the AP. option rrm_neighbor_report '1' turn on the ability for each AP to give a list of nearby other AP's to roam to the device so the device can scan faster. If you only have AP, this would be pointless. You have to populate the neighbor report manually or with scripts that are available. In my case, I have 3 AP's and I just set the neighbor report manual…

[_FailSafe]

Got it! I do agree that there is more documentation for Dawn. I have used Dawn in the past and have mixed feelings on it. I thought I had read here in the forum that Usteer was likely going to gain more mainline support from Openwrt devs and be more-or-less "official". I'll try to find and link to that in a bit.

FWIW, I started this thread because of genuine curiosity (and I know @Lynx shares in this as well) about the topic. I did not start the thread because I was actually having any issues. On the contrary, my Apple devices never exhibit roaming issues with my current configuration.

I'm a tinkerer, though. So I will probably give Dawn another try

[patrakov]

@Lynx

But see this: Proper configuration of 802.11k and 802.11v - #28 by account4538

The problem is, some devices (e.g. Linux laptops) do not react to this information by themselves, and need to be steered.

[Lynx]

Ah so maybe a helpful summary is like this. Please anyone correct to help us all converge.

802.11k and 802.11v can be enabled using:

      option bss_transition '1'
      option wnm_sleep_mode '1'
      option time_advertisement '2'
      option time_zone 'GMT0'
      option ieee80211k '1'
      option rrm_neighbor_report '1'
      option rrm_beacon_report '1'

Amended to correct timezone.

And in addition by installing static-neighbor-report. Without the latter 802.11k and 802.11v is compromised.

However even with all of the above, this will only get leveraged by savvy clients.

Less savvy clients would need forcing by DAWN or usteer.

[patrakov]

To be honest, I don't know why (and whether) the timezone is needed. Other than that, 99% correct.

The remaining part of the puzzle is that, without scanning, the client does not know the signal levels of other BSSIDs belonging to the correct SSID. And with "good-enough" signal, the client doesn't scan. DAWN forces the scans and therefore gets all the signal levels needed for an informed roaming decision.

Enterprise APs get the same information just by listening to the 802.11 frames sent by the client, no scans needed.

[Lynx]

Phew? BTW dumb question: OK or not for all hostnames to be default OpenWrt?

[patrakov]

Not OK - the DAWN hearing map will be confusing then.

[Lynx]

Seems like that's another possible pitfall.

By the way great thread and thanks so much everyone for the contributions.

[eR2022]

My recommendation is using DAWN's kicking mechanism Number 2.

kicking=2

It's using bss_transition_request instead of wnn_disassoc_imminent .
It's a "healthy" way for roaming. Instead of using the score mechanism with the "kicking" method.

[Lynx]

@patrakov

Enterprise APs get the same information just by listening to the 802.11 frames sent by the client, no scans needed.

Interesting. Is this definitely not implemented by OpenWrt or part of the standards?

[patrakov]

This does not need any new standards - just a separate monitor-mode radio, or, if all APs are on the same channel, coexistence of monitor and AP modes on the same radio. What's missing is the software that would sniff on the monitor interface and infer the signal levels from "foreign" clients.

[Lynx]

Sorry to bombard you @patrakov and others. @_FailSafe look how simple the DAWN documentation is:

Setting up DAWN and band-steering in OpenWrt

It's tempting just to use this, no?

Or is it riddled with bugs and problems? Is it being actively maintained?

The luci-app-dawn looks pretty cool?

[patrakov]

The default configuration needs to be thrown away and rewritten according to the documentation - but that, and the lags due to the extra scanning if more than one channel is used, are the only problems encountered so far.

[eR2022]

And lack of roaming daemons

[_FailSafe]

Confused... you just posted this regarding Dawn: Proper configuration of 802.11k and 802.11v - #58 by eR2022

[eR2022]

Read what he said, and read my answer .

[_FailSafe]

I think I get it now.

[Lynx]

It seems there is a consensus that usteer or DAWN is needed. What's less clear to me now is which to opt for.

GitHub for DAWN looks active:

Commits · berlin-open-wireless-lab/DAWN

usteer less so:

Commits · blogic/usteer

Assuming I have correct links?

Can anyone confirm if the luci dawn app works well I. 22.03?

[_FailSafe]

@patrakov

rewritten according to the documentation

Referring to the guide here? https://openwrt.org/docs/guide-user/network/wifi/dawn

Or are there additional items to take into consideration beyond that and
@eR2022's callout here:

@eR2022

My recommendation is using DAWN's kicking mechanism Number 2.

kicking=2

[patrakov]

The app works fine in 22.03, but it is just a read-only view into the wireless network.