Band Steering (802.11k / 802.11v / 802.11r) support in 18.06.1?

Installing and Using OpenWrt Network and Wireless Configuration
#1

I'm using the Xiaomi Wifi 3G Router with the latest OpenWRT 18.06.1.

I'd like to realize some kind of Band Steering and let clients switch from 2.4Ghz to 5Ghz and vice versa.
Actually, putting both SSIDs identically does not really work great: Getting out of reach of the 5Ghz network lets devices connect to 2.4Ghz, but they remain there and don't switch back (even hours later) to 5Ghz.

I've read that this could be possible if one instance (process) of hostapd is used for both radios - but- how can i configure openwrt to just use one hostapd process?

Any ideas ? Thank you!

#2

You can't, not without a rather major development effort to refactor OpenWrt's network management (netifd).

#3

isn't something similiar possible with a script, checking 5ghz capable MAC addresses and disassociate them from 5ghz, if their RX/TX gets "too strong"?

As far as i understand, neither Mesh nor 802.11r Configuration would help in this case ?

1 Like
#4

always makes me wonder if "band steering" is the cause (marketable feature) or the cure for almost every os's inability to decide on its own .... android had a preference selection once, on windows its burried in the settings dungeon of the wifi-device driver ...

#5

you're absolutely right... But what's the conclusion?

#6

Other threads:

1 Like
Simultaneous dual band (2.4/5ghz)
#7

802.11r needs smarts in your client - and not many devices do this, even today some 10 years after the standard was ratified. The client chooses to jump networks, and starts encryption with the new before leaving the old -so it's just a fast change. Mesh won't help either because again it's up to your client when to change, not the AP. Aruba and other enterprise do this by tracking signal strength from multiple AP - not just the active association - and sending a disassociate and refusing to reconnect for a period of time when it knows the client can jump to a better AP - usually it works, sometimes not.

You can fake the disassociate with a script (run it in cron), but it is a blunt hammer approach, and unless your client is in a stronger 5G area when you hammer it, it'll jump back onto 2.4G anyway. I 'encourage' 5g by winding down the power of my 2.4 network - it goes through walls better for the true deadzones, but all else being equal, the 5G is always the first choice (so it stays sticky on 5G). If someone ends up on 2.4, though - they tend to stay there.

#8

You could use 802.11k for asking the client what is in his range and send some 802.11v fast bss transition to the client to switch to 5Ghz. Then 802.11r would work too. :slight_smile:

There are different milestones you have to do:

  • Network-Manager Patch has to be accepted for supporting 802.11r (if u use network-manager...)
  • Fast BSS Transition be reachable via ubus

When some daemon could be implemented independent of the hostapd. Personally, I think this would be the nicest solution.
I experimented with deauthing clients, trying to supress probe responses, deny authentication tries. There are always corner cases. And often you need some "hearing map" approach. And this only works if you have some static scenario or you can use some antenna to scan for clients. In addition, you have mac-randomisierung when the clients scans and other challenges you have to cope with...
There are techniques sending a channel switch announcement to the client without switching the channel. For example the 2.4 GHz and 5 GHz run with the same BSSID and the 2.4 GHz would send some channel switch announcement to the client that it now switches to the 5 GHz frequency. However, the interface won't switch the frequency but the client will switch. to the new interface which has the same BSSID. This is some kind of seamless handover.

In addition, 802.11q introduced important information about the channel utilization and the number of connected clients. With that information clients could make good decisions.

Why load balancing matters?
If you have several APs in your network cooperation becomes important. Clients often do not know how the backhauling looks like. What happens if the AP is connected via powerline link, or is some part of a mesh network.
In addition, SDN is some feature trend that can be optimized when APs have the ability to steer clients to different APs in the network.

I wrote more in a blogpost. :slight_smile:

1 Like
Distribute users across Access Points evenly
#9

If u are interested those hearingmap approaches, you can try use my daemon DAWN and read my GSOC
The daemon is similar to The Cisco agressive load balancing or lancom approaches. But my approach works WITHOUT some central coordinator and configuration (of course u can configure it). Everything is decentralized (making it complicated). It implements bandsteering even between different APs. But as I said it has those hearing map limitations. That's why I'm not actively deploying it anymore until I implement 802.11k/v. Maybe I will release some post explaining why and what is so complicated.

2 Likes
#10

When will we see official support for 802.11r,v and k in OpwnWrt?

#11
3 Likes
#12

So the latest addition was k about 2 months, well well. A proper module for Luci is still missing, right?

I'm using 802.11r with wpad-full since a while and it is fine. The problem is that openwrt creates one hostapd instance per wifi-device, so one cannot roam between bands. This issue has been pointed out in this thread too.
Any idea when this will be changed or the ubus-communication between instances will be enabled?

#13

Why? You can roam between those bands?

#14

2568db3fff7be1be848d490a7f53af42ec14b257, 24b97579d20b6ac6df81654a953386d2912fc324, 3ee767086d306f8095b7301262b0fe053a0b9f50 and c888e17e067edf36c4dc798771479170003f967d are laying the groundwork into that direction, yes, it's not quite there yet, but it's under development.

Just to clear up the obvious, neither of this is necessary for client-side roaming, that works pretty well already (to the extent of the client's abilities - and that's what 802.11k/v/r are helping with, right now already). AP side band-steering is another topic, which will require said netifd refactoring to allow using a single hostapd instance for multiple wireless interfaces.

1 Like
#15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.