In experimenting with 802.11s, I've found that devices may tend to "stick" to one node over another, even while roaming. I've seen bits here and there referring to "aggressive roaming"--that is, encouraging devices to switch to routers (and even to different spectrums/frequencies), to better share load and get higher throughput.
My questions are:
- Are there "aggressive roaming" settings that do this? What's the proper name for such setting(s) (so I can reference it appropriately), and how does one add such support to their node(s)?
- In a similar vein, can we add support for additional features, like 802.11k, r, and v? How does one go about adding support for those?
Finally, what other features or settings would you recommend for an 802.11s network? I'm configuring my own for the first time, and I'm trying to collect data to write a beginner-friendly guide to get started with some best practices and features that are helpful. What else can/should I add?
One way to handle such clients would be to disconnect them forcibly if the signal dips below a certain threshold. The technical term for it is slipping my mind...
Some 802.11k/r/s support is already there AFAIK. Even in LuCI, but you need a driver that supports it etc.
There is full support for 802.11r in LuCI as long as you have the full wpad installed (instead of wpad-mini).
But as 802.11r requires knowledge of the unique IDs of all participant APs in the roaming to be available in all the participant APs, I am not sure how compatible that is with 802.11s. (I have never used 802.11s to that is pure prejudice on my side)
@Shidell did you figure out the 802.11r part? thanks
I haven't tried to implement it. Did you have a question regarding 802.11r?
@hnyman nice! will try it out now. I was doing similar thing by installing full
wpad and using LUCI like you suggested.
@Shidell I was using iphone 6S to test out 802.11r but moving from AP1's location to AP2's location, the iPhone still holds on to AP1. Constantly checking via LUCI.
Note: both AP1 and AP2 signals overlap quite a bit.
On top of that, it switches to 2.4GHz band after a few minutes. Hence my quest for band steering
In my research I found there has to be one
hostapd instance for both radios (2.4 and 5 GHz). But LEDE creates two instances/processes. This is useful in both fast-roaming and band steering
So how can I have only one hostapd instance controlling both radios?
I guess I was trying to knockout two birds with one stone.
I haven't experimented with band steering, but it is something I'm interested in. Where did you discover that hostapd needs to have a single instance (for both radios) as opposed to two in order to enable band steering?
hostapd has only pretty basic band steering capabilities - and for those to work, both bands would need to be handled by the same hostapd process, but so far LEDE starts independent processes per wlan card which makes it a little difficult
-- from a user in IRC channel
Those are the links I have so far
My understanding is that since there are two hostapd processes, one for 2.4GHz radio and another for 5GHz radio, a handover needs to work over physical wlan cards/radios and hostapd processes. So having a single process might alleviate this issue somewhat (?).
thanks for the tutorial. that user did a good job in explaining and putting together the instructions.
I removed setting from LUCI and re-did them in config files. While doing this I caught the error: the mobility domain was wrong.
Fixed it. Tried it out with iPhone 6S again. Seems to be working. It does switch to AP2 but connects to 2.4GHz. (hence my quest for band steering).
I'm using 802.11r and roaming between two AP is working fine with Android and Windows. Iphone seems to be more picky but it still roams.Unfortunately, while roaming works, it seems that the Iphone and iPads cannot reconnect after going into power saving modes. And I had to reboot to get it to reconnect. If anybody has solutions , let me know..
Are you still combine 802.11s and 802.11r together? I setup a encrypted 802.11s for roaming, however the router act like you said. it will not transition fast.
When I enabled the 802.11r, the wifi will all gone. I don't know if the LEDE support 802.11s with 802.11r together.
Works quite well together in 18.06 and later
Even with 802.11r the choice of roaming is ENTIRELY up to the client. Band steering basically works by refusing the client until it tries the AP that the band steering algorithm wants it to. 802.11k allows the AP to tell the client a list of APs to try but again it's up to the client to do something right with this info.
Edit: one useful way to improve roaming is to adjust power output on the APs downward so that the client only hears one or two APs at any given location
802.11r is only a mechanism for a client to continue using the same encryption key after it moves to a new AP. The APs transfer keys among each other over the backhaul network. This saves the considerable amount of time that would be required to generate and exchange keys over the air for a new connection.
802.11r does not at all address the issue of the client finding or being directed to the AP with the best signal for it.
I have written some modifications to hostapd to drop a client when their signal becomes weak. In my use case at outdoor festivals, I just want to be rid of that client as he leaves the "hotspot" area and becomes an excessive burden to the AP. Trying to work someone with a weak signal means that the AP will be doing many retries and has to reduce the bit rate for that client.
Kicking the client off actively is much preferable to reducing AP power forcing him to run out of signal and eventually drop passively. Again it is resource expensive to work someone on the fringe of coverage, and you exacerbate that situation by reducing AP power as the way to make clients drop. The clients that you do need to keep should have a strong signal for the best bit rate and fewer retries.
A more sophisticated than simply drop when weak would to poll the other APs to confirm that the client has a better signal at another AP before dropping him. It would seem that would require running a monitor mode interface on every other AP and collecting a log of the signal strength of packets received from clients associated with other APs.
Kicking the client off actively is much preferable to reducing AP power
forcing him to run out of signal and eventually drop passively. Again it is
resource expensive to work someone on the fringe of coverage, and you
exacerbate that situation by reducing AP power as the way to make clients
drop. The clients that you do need to keep should have a strong signal for
the best bit rate and fewer retries.
Well, you want to be running low power so that you can re-use the channel for
another AP closer.
A more sophisticated than simply drop when weak would to poll the other APs to
confirm that the client has a better signal at another AP before dropping him.
It would seem that would require running a monitor mode interface on every
other AP and collecting a log of the signal strength of packets received from
clients associated with other APs.
This is a good thing to be able to implement.
I run the wifi network at the ScALE conference. We deploy about 120 APs through
the Pasadena Convention Center to support everyone. Currently I don't do
anything with 802.11r/k/v but would love to be able to do so.
Can you share insight on how you improved your OpenWrt config over time and how you get 120 APs to work as one single network?
- Do you have exclusive permission to run wifi on Scale? Do others (exhibitors or vendors?) run their own wifi networks?
- How many clients do you have connected per AP on average?
- What it the biggest number of devices per AP you have seen connected before it just doesn't work anymore?
- Do you use some routing protocol like babel?