Struggling big time with 2.4Ghz stickiness

Hello,

I’ve a mesh setup with 3 AP’s, all running on official latest, and both bands have the same mobility id.
My issue is that most of the time i find myself connected to the 2.4Ghz even if 5Ghz is closed to it in terms of dBm (or even higher).
I’ve tried to enable r/k/v and i know i need DAWN or usteer or https://github.com/Fail-Safe/nrsyncd/tree/feature/activity-overlay-and-parsing but i also understood that they can mainly suggest an AP.
What i dont understand is why my old setup wasnt showing this behavior. I have the exact same devices and reducing 2.4ghz power has never been a thing in my environment
Is there anything wrong other the missing software above that i could try?

Would differentiating mobility ID between 2.4Ghz and 5Ghz do something?
Do i really have to split the networks names?

FLINT

root@Flint:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi'
        option band '2g'
        option channel 'auto'
        option htmode 'HE20'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ocv '0'
        option ieee80211r '1'
        option mobility_domain 'xxx'
        option ft_over_ds '0'
        option ieee80211k '1'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option bss_transition '1'
        option time_advertisement '2'
        option dtim_period '3'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi+1'
        option band '5g'
        option channel '36'
        option htmode 'HE80'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ocv '0'
        option ieee80211r '1'
        option mobility_domain 'xxx'
        option ft_over_ds '0'
        option ieee80211k '1'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option bss_transition '1'
        option time_advertisement '2'
        option dtim_period '3'

config wifi-iface 'wifinet2'
        option device 'radio1'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id 'xxx'
        option mesh_fwding '1'
        option mesh_rssi_threshold '0'
        option key 'xxx'
        option network 'lan'

RE650

root@RE650:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option band '2g'
        option channel '11'
        option htmode 'HT20'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ieee80211r '1'
        option mobility_domain '1A2B'
        option ft_over_ds '0'
        option ieee80211k '1'
        option time_advertisement '2'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option bss_transition '1'
        option ocv '0'
        option dtim_period '3'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option band '5g'
        option channel '36'
        option htmode 'VHT80'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id 'xxx'
        option mesh_fwding '1'
        option mesh_rssi_threshold '0'
        option key 'xxx'

config wifi-iface 'wifinet2'
        option device 'radio1'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ieee80211r '1'
        option mobility_domain 'xxx'
        option ft_over_ds '0'
        option ieee80211k '1'
        option time_advertisement '2'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option bss_transition '1'
        option ocv '0'
        option network 'lan'
        option dtim_period '3'

WR3000H

root@WR3000H:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi'
        option band '2g'
        option channel 'auto'
        option htmode 'HE20'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ocv '0'
        option ieee80211k '1'
        option bss_transition '1'
        option time_advertisement '2'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option mobility_domain 'xxx'
        option dtim_period '3'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi+1'
        option band '5g'
        option channel '36'
        option htmode 'HE80'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'mesh'
        option encryption 'sae'
        option mesh_id 'xxx'
        option mesh_fwding '1'
        option mesh_rssi_threshold '0'
        option key 'xxx'

config wifi-iface 'wifinet2'
        option device 'radio1'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'sae-mixed'
        option key 'xxx'
        option ieee80211r '1'
        option mobility_domain 'xxx'
        option ft_over_ds '0'
        option ocv '0'
        option ieee80211k '1'
        option bss_transition '1'
        option time_advertisement '2'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option network 'lan'
        option dtim_period '3'

You can adjust nearby AP "cell density" to minimize overlap. First set density to one, then switch off 2 at a time and make a room survey using https://play.google.com/store/apps/details?id=com.ubnt.usurvey&hl=en-US
increase density where it is more than minimal overlap.
ignore KVR unless you have VOIP phones explicitly requiring that. or later you find devices that never move 2.4->5 or are stuck to faraway AP.

I don't mean to be hostile, but a mesh is something very different, ie a means of interconnecting access points using a wireless backhaul. What you are trying to do is set up seamless roaming from one access point to another of your user devices.

You have added config options for 802.11r fast transition and talk about Dawn. This almost all the time makes for a very complex and unnecessary configuration - that, as you are finding out, does not work very well in small domestic or office environments. There are many threads on this forum with lots of useful advice about roaming. Try doing a search and some reading. You may have had apparent success previously, but things change, and now it no longer works.
While you are researching, perhaps one of the regulars with "roaming" experience will chip in....

2 Likes

First set density to one, then switch off 2 at a time and make a room survey … increase density where it is more than minimal overlap.

Can you explain the increase density part, what should I aim for? I thought cell density was to limit devices that have at least a certain transfer rate so that they might go elsewhere.

Also isn't kvr meant to improve this behavior? Is it a standard failure or a lacking implementation?

Agreed,

Some of the simplest mesh use the 2.4 radio for wireless back haul and 5 for wireless clients

No worries, my intro was to give context, I'm plenty aware what 802.11s does and so kvr (or I think so based on the last week readings I had).

As you can see from the configuration the 3 APs are in a mesh and I thought it could give hints on whether some conflicts might arise in my setup.

When I was talking about a previous setup I was referring to a setup without openwrt to highlight that my devices can actually stay on 5ghz

low rates = higher range ? explain what? basic physics and error correction?

I can definetly try that although as stated above meshing and band steering are separate things, so how can this explain my issue? Since my area is quite congested on 2.4ghz I get at most 20/30mbps so I decided for the 5ghz backhaul because I can have iperf3 of 400+ Mbit/s between each AP

An 802.11s mesh on the same radio as 802.11r is fundamentally incompatible.
802.11s requires all mesh nodes to be using the same channel.
802.11r requires all access points to be on different channels.

It looks like radio1 is the 5GHz radio and is your mesh radio, so all nodes must be using the same 5GHz channel. So in turn, the 802.11r/etc will fail on 5GHz and you will get your 2.4GHz stickyness....

3 Likes

That's an interesting notion there, I always find that fast roaming is to avoid 4 way handshake when the device switch to another AP so that it doesn't have to re-auth which is a long process. Can you quote a source? Why would the channel be a limiting factor in your opinion? Isn't the connection also based on the different MAC address of the base?

Fast roaming is normativelly under .6s , you dont gain much over 1.few seconds of 4-way handshake, voip phone still clicks and video buffers and game freezes visibly....

Mesh nodes have to communicate between them, there is no other way than them all being on same channel. Which means AP-s in same band too will share same airtime.

"source" is common sense.

@maxdd if @bluewavenet has not properly introduced themselves, they are the author and maintainer of mesh11sd and opennds packages.

If you would like sources:

2 Likes

I was honestly more interested in the statement that 802.11r need different channels for roaming.
The fact that a mesh need the same channel is common knowledge as you showed in those links
Here https://openwrt.org/docs/guide-user/network/wifi/roaming?s[]=802&s[]=11r there is no mention of it

My wording was not strictly correct as 802.11r can function on a single channel network, but this is very sub-optimal.

There are lots of threads on this forum and many other places, but from my own experience, advantages of channel separation are:

  • Minimizes co-channel interference (from same-channel APs) and adjacent-channel interference
  • Higher signal quality, fewer retransmissions, and up to 50-70% better throughput in overlapping areas.
  • Improved capacity & throughput allows more concurrent client sessions without contention.
  • Reduces "sticky client" issues where devices cling to weak signals.
  • Clients can hand off to the next AP faster, as channels don't conflict during transitions.

"So how does a mesh cope?", you may well ask.
In ap_to_client / client_to_ap traffic, there is very little in the way of "on the air" collision avoidance other than listen for a lull before transmitting. Compare this with a properly configured 802.11s mesh, where node to node communications on the same channel use mesh_hwmp_rts for active collision avoidance.

@maxdd I have a mesh environment similar to yours, with 3 openwrt access points on the latest version etc etc, and had the same issues as you. I tried everything I could find, dawn, messing with configuration, etc.

The only thing that reliably fixed my issue in my environment was: lowering the 5ghz width to 40mhz as it gave me a little more range on the 5ghz on my environment, and lowering tx power on the 2.4ghz radios, this made the clients prefer the 5ghz band more and that fixed my problem.

I hope this might be of help to you, good luck.

Hello Fernando, thank you for taking the time to answer this post. I might be selfish but I'm glad I'm not the only one. Hopefully the community will soon realize that actions shall be taken to optimize this area of the project. It is a pity that we have powerful HW and high theoretical speeds but we need to clip our router wings to resolve these problems.

I'm playing around a bit with a small ubus based kicking tool. I wanted to avoid blacklisting my MAC or splitting SSIDs so I came up with a basic strategy that works for me. Some ppl accept deactivating and reactivating their wifi, to me it feels just stupid