I'm new to Openwrt, and so far really blown away by the capability and supporting community. I have a basic wifi networking question - sorry... I have 6 x 2Ghz & 5Ghz AP and o1 x 2GHz, 5Ghz & 6Ghz AP. My question is how to configure mobile devices to pick the best AP when moving around. For example my iPhone 15 Pro wants to hang on to the 6Ghz AP when a 5Ghz AP is 10ft away. Hanging on to 6Ghz can give really poor connection speeds as you move away from that AP.
So - my question... is it possible to configure connection tollerances by AP to drop the connection so the device will pickup a nearer - better connecting AP? Or is there a differnet way to manage this?
Try to lower the 6 GHz AP TX power to something like 12-15 dBm. This way your iPhone will quicker reach -70 dBm when it starts considering other networks for roaming. Don't worry about the range. Range is determined by your iPhone transmit power, which is typically the value above. When 6 GHz drops to -70, ensure that there's a 5 Ghz network with at least -62 dBm or ideally -58 dBm signal with the same WiFi standard as your 6 GHz AP. More details:
You could try usteer (preferred by me) or DAWN to actively kick devices when signal level drops below a certain threshold. However, that is aggressive and might not work at all. If you disable kicking usteer has a nice thing to it that it fills neighbor networks list for your AP, so that can make it easier for iPhone to roam.
21 dBm might be pretty high considering 7 AP that can do 5 GHz. We don't know of course how big is the property. Power for each AP should be set so that there's good enough signal at the edge of every cell and in overlapping areas. Usually -70 to -65 dBm is a good value.
It's quite a tall property, built in the 1880's - with very thick, solid walls. It is 3 floors plus a basement, so I have had to put AP's on 2 rooms on each floor (top floor to be completed). The devices can stay connected to AP's in rooms below through the timber flooring.
I have implemented WLAN roaming on 5Ghz and 2Ghz radios, assuming that would switch as we move about - but so far that doesn't seem to switch unless the signal strength gets too low. Adjusting 6Ghz power makes a lot of sense.
If you mean 802.11r, then this actually means "WiFi quicker authentication when roaming". When using WPA2 PSK or WPA3 SAE, it doesn’t bring much benefit, but can actually introduce hard to debug issues. It should be disabled.
802.11k and v usually do no harm and can be all enabled. With usteer or DAWN (with kicking disabled) they help your devices to find your other APs quicker.
If possible, connect APs with Ethernet for better performance.
I thought faster auth when roaming is really only applicable when you needed "realtime" stuff like audio calls whilst walking around? I never ran into any issues setting it. But maybe I was just lucky.
Do you have any links / edge cases you can point me to?
I can see that leaving it disabled reduces complexity. So leaving disabled is a reasonable default if you can use other knobs to get everything working?
Similarly with below tuning power of the AP's and minimum basic rate before trying usteer and active /forced roaming...
I missed that. Is this a mesh system?
Further discussion on transmit power:
FYI having a look at airport utility with the wifi scan enabled in setttings? (Or ios wifi scanner of your choice) to look at the received signal power of the different AP's and map them out in your building manually?
Similarly can use hearing maps from usteer....
(i.e. per above @qunvureze outlining -70 to -65dBm being close to what should trigger roaming behaviour on most clients?)
As mentioned above as well, no point going too high on AP transmit power as then you end up with an unbalanced link.
At least with iOS i've found the devices can be quite sticky. I haven't done serious work to try to narrow down the problem. Setting minimum basic rate + tuning transmit power has been sufficient. Usteer is nice but I'm yet to log and see if it's actually helping.
Usteer with kicking / aggressive roaming is a big tuning issue IMO. Especially if there's a client device that doesn't handle "AP temporary full" events and/or is single band?
This guy also recommends to keep all rates available to minimize hidden node effects where 2 stations opposite of each other connected to the same AP can’t hear each others management traffic and therefore are prone to causing collisions.
My experience with iOS and macOS clients is that they are happy to roam as long and proper signal level overlap is present. Android is much more hit and miss due to all vendors doing their own thing.
I can find people that are having problems on the forum yes. =P I will obviously have to do more reading =) I wouldn't be asking if I thought I could easily find or determine the mechanisms when it works or not but sure.
I'm in agreement that it would add complexity and as you say people encounter problems? I must have been lucky, or problems rare / i'm not noticing any issues.....
What are the mechanisms that cause these failures? Bad clients? Bad configuration / high configuration complexity?
Finally, when would it be worth turning it on? Or is it that four way handshake with a new AP basically doesn't take any time so who cares?
I had bad times with one iPad and one MacOS client sticking to an AP in nonsensical ways (i.e. all the way down to -80dBm or lower). But all the other apple devices were all roaming fine haha.
I'm with you. My opinion is that Android is a disaster in fragmentation and inconsistent experience in quite a few ways.
I agree with you there. That problem is solved in my case by adequate band planning =P Given we're talking a small deployment and 6ghz wifi that shouldn't be an issue here. (But I also go 40MHz channels specifically to get enough channels....) If everyone wants 80MHz/160MHz on all AP's I can see problems =P
I can see that retries on the edge could also make things bad. But then your devices should be roaming before then in a properly configured network? But I guess if they're roaming early, they'll not use the lower rates anyway?
No - all AP’s have Ethernet connections to the network. Just need to connect up to the top floor to have Ethernet available top to bottom. Maybe old fashioned but try to avoid mesh whenever possible.
This is my only need for fast roaming. We don’t get Cell/Mobile signals of any real use in the house so rely on WiFi Calling/Whatsapp/Facetime for calls and speaking while moving from room to room would be nice. Video also but less of a priority
Sorry - I should have been more specific - this is Openwrt after all! Yes I do mean 802.11r. I didnt know about the different with methods impacting switching speeds - another area to tune and fettle.
With 802.11r, it's worth enabling when using WPA*-enterprise, because it usually involves contacting a server and all this takes time to happen. Especially if the server is in an over-provisioned cloud. Delays might rack up even to 1-2 s. However with "simple" passphrase WPA2/3, you usually get hundreds of ms range max. It might not be easy to hear this during a call or there might be a small hiccup.
I believe people encounter problems because there are many knobs to configure and it's easy to mess it up. Some devices might not handle it exactly as described in standards or implemented in kernel/hostapd/driver/etc. The worst case could be when a device gets a new key, but it isn't actually valid with the new AP. Device tries to communicate but fails even though the RSSI is good. It needs to timeout and try the regular auth process from scratch. Or it might be stuck trying the old key until user does something to start from scratch, like the famous "turn it off and on again".
Look, if you have time to debug and closely verify it actually works, then sure, go for it. syslog with proper hostapd debug level provides all the clues to see if it succeed or not. There are also threads on this forum where people share their succesful configs.
I can see that retries on the edge could also make things bad. But then your devices should be roaming before then in a properly configured network? But I guess if they're roaming early, they'll not use the lower rates anyway?
What if this is the edge of a building and there's nowhere else to roam to? That's sometimes a problem in dense areas that things work fine inside the building, but once you're close to the window hell breaks loose. Your signal level is fine, but the amount of interference coming from the opposite building is causing massive retries. There's a higher probability that the lowest rate frame will still get through all that and let you continue your call.
Yeah so with PSK as previously mentioned if you're in the order of 150ms it's probably not noticable either way. Whilst if you're using a radius server things could get bad.
You make a great point example here, thanks! Something I didn't consider.
Attenuation at the edge of a building is certainly a case where the interference could be at a meaningful level.
Free space path loss to -80 or -90dbm is in the order of hundreds of metres right?
Low emissivity glass plus double brick / reinforced concrete, plus a building a hundred metres from the next closest building is obviously the solution =P
That's sometimes a problem in dense areas that things work fine inside the building, but once you're close to the window hell breaks loose. Your signal level is fine, but the amount of interference coming from the opposite building is causing massive retries. There's a higher probability that the lowest rate frame will still get through all that and let you continue your call.