I think this 2:
option rrm_neighbor_report '1'
option rrm_beacon_report '1'
Are automaticaly saved in hostapd conf when enabling 802.11v and k, and shouldn't be on wireless conf
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 manually in startup and check every 5 minutes in a cronjob to make sure the list is still there because any changes or restarts deletes the list.
I don't use 802.11v, beacon reporting (option rrm_beacon_report '0'), DAWN, or usteer so I don't have any info on that but I do use 802.11r (fast transition roaming)
Ah, interesting. Is this something that usteer does @_FailSafe?
@account4538 what's your reason for eschewing usteer and dawn? Is it that they seem to violate keeping things simple and elegant? That's what's kept me so far. But possibly unjustified as perhaps there are good reasons for the complexity such as just offering the potential for fine tuning.
But it may be that at least some of the benefits of 802.11k and 802.11v cannot be realized without usteer, dawn or a user script or otherwise?
Certainly it seems that this aspect of WiFi configuration (the purpose of this thread) is rather complicated and confusing.
Whilst a 'tick to make things work' button might be too ambitious, perhaps there is a happy medium between the latter and the present can of worms.
you can use static-neighbor-report .
setup once, it works flawlessly, no cron job .
1 Like
Does that survive reboots?
Do you agree with this:
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'
Plus modification of time zone for 22.03 to set 802.11k and 802.11v?
Seems fine,
for your Time Zone check:
cat /etc/TZ
About static-neighbor-report , it's a service and survive reboots .
1 Like
So much great and exciting new info coming to light in this thread! Could you help us understand how static-neighbor-report plays into the bigger picture here?
Is it beneficial even in addition to Usteer or Dawn? Is it a replacement for those?
1 Like
When using Dawn or usteer it use the rrm_nr list to decide which AP to roam .
That list is not always available..
This static-neighbor-report is filling manually this list, for good .
Regarding the neighbor report, let me remind you that DAWN does it automatically. So maybe it would be easier to use it instead of usteer?
Anyway my own impression so far is that steering between bands is a horrible idea in my place. Even at -76 dBm on 5 GHz (i.e. what most devices treat as "unusable, switch immediately") vs -55 dBm at 2.4 GHz, 2.4 GHz is slower, no matter which channel is chosen. Besides, if all APs for a given SSID are on the same channel, then there is no need for off-channel scans, and therefore no lags. The only reason to have anything on the 2.4 GHz band is a device that doesn't support 5 GHz - but for it, a separate SSID may be a better idea.
Sorry, but that is not a productive approach to this thread. Not sure if there was some missing humor in-between the lines there, but we're here to figure this out as best as possible. Hopefully through open dialogue we all help each other improve our understanding, and with a little luck, our wireless configs too.
1 Like
So are you indicating DAWN doesn't need static-neighbor-report? What happens if we just use the latter plus:
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 include proper timezone?
Will that give the benefits for 3x APs over a big house thar Apple mention in their blurb about 802.11k and 802.11v?
Or will it do nothing without usteer or DAWN?
All of this seems like a huge can of worms so I'm very grateful for this thread to help unpack some of the complexities and hopefully converge on good best practices.
Correct, DAWN uses multicast to detect all its nodes, and populates the neighbor report with information gathered this way.
OK gotcha so DAWN doesn't need it but usteer and neither usteer nor DAWN does need it.
I'd value your thoughts on no DAWN and no usteer but with it.
If using dawn, you should set set_hostapd_nr = 2
Still, I recommend use static-neighbor-report, and set set_hostapd_nr=0
Mobile devices are supposed to roam by themselves when the signal level is too low. For Android, this is something like -70 dBm. What DAWN brings to the table is global awareness of the signal level from each AP, because it asks each AP to ask the connected clients to send the report about all APs (but, if done incorrectly, i.e. over more than one channel, it is a major source of lags). Therefore, the AP can tell the client to roam, instead of lingering on a weak AP "thanks" to the built-in roam criterion, thus achieving better throughput.
What's the difference between the latter and 802.12k and 802.12v without DAWN?
Supposed yes, but sometimes it can stay even on -72dB even if you stand next to the other AP.
That's why we should use roaming daemons.
1 Like
802.11k + v are just mechanisms to provide the topology to the client, which is then mostly ignored. DAWN actively tells the client to roam.
Also, 802.11k defines a message that can be sent from the AP to the client that forces the client to report the signal level from the indicated BSSIDs - but it is DAWN who tells the AP to actually send this message.
Forgive my naiveness, but doesn't Usteer do the same when set as such?
# The network interface for inter-AP communication
option 'network' 'lan'
# Disable network communication (0/1)
option local_mode '0'
Forgive my naiveness, but doesn't Usteer do the same when set as such?
I have tried usteer in the past, unsuccessfully, and prefer DAWN due to much better documentation.
Anyway, the state of the art is not 802.11k+v, but "virtual AP". This is a feature found in enterprise APs where multiple physical APs share the same MAC address and the same BSSID, and measure the signal levels continuously. Then they decide which one is to talk to the client. No roaming needed, from the client's viewpoint. Unfortunately, it is not achievable on OpenWrt.
3 Likes