Hello guys, I was talking with my friend about routers. He was complaining about his asus ac65p (with stock firmware) that he needs to switch manually Wi-Fi connection when he’s out of range of one network and connect to other access point. I’ve started wondering if there’s an option in openwrt to create rule that kicks him out of his first Wi-Fi if the signal is like -80 dBm and the other router will let him join his second Wi-Fi. Is there any option in openwrt that allows user to create such a rule?
You can set the minimum RSSI on an AP and that will tend to kick off sta devices with poor signal quality. However, this can cause headaches if a client keeps trying to reconnect to that original AP. You can also use 802.11r (fast roaming) and a few other standards to try to coordinate and improve roaming performance, but not all devices work well with these methods.
Ultimately, roaming is a client side operation. The best way to handle this is to tune the APs appropriately... make sure the placement is optimized to the extent possible, reduce AP power to minimize overlap, and ensure that all neighboring APs are on different channels. Obviously they should all use the same SSID and password and should be on one L2 network.
This video talks about how to tune the AP performance to get high quality roaming. While this one deals with Unifi APs, the concepts are the same for all wifi systems and can be applied on any hardware/firmware provided that the controls are exposed to the user.
I personally do not use any 'tricks' to force roaming... just good placement, power levels, and channel selection to encourage clients to roam... and this is generally seamless in a well tuned environment.
If OP needs faster transition, shouldn't APs be on the same channel?
Different channels improve throughput and channel utilization, but the same channel can (but doesn't need to, 802.11r and background scanning do mitigate this to a considerable extent these days, especially modern chipsets have gotten much better in this regard, because they need to, for DFS and similar split-channel features) slightly speed up handover between BSSIDs.
As @slh covered, it is far better to use different channels. There are two reasons that this can really improve performance:
two APs broadcasting on the same channel create noise/interference for each other. Think of trying to listen to one person while a simultaneous conversation is happening next to you where there are other people who have very very similar voices. It can be hard to 'isolate' the speaker you're trying to listen to in that scenario. But, if everyone had distinctive voices, it would be much easier to understand just the one you want to hear.
When the signal quality (signal to noise ratio, etc.) is being evaluated, it is easier to identify which AP is which when they use different channels, so the client can make good decisions about when to roam and to which AP they should associate.
However, once the client has connected to an AP, it has to disconnect (or at least, to change to another channel, thus blocking all traffic) before it can even know about the second AP. If APs are on different channels, most clients will stick to the first AP, even when there is another AP with better signal, until the connection drops.
I'm quite certain that this isn't true. For example, look at the wifi menu on your phone or computer while you are connected to your normal wifi. Assuming you are within range or other APs, you will see the SSIDs show up in the menu. Also, having worked with other devices that actually must be connected to a given wifi network and then scan for other available networks as part of a setup process, I can tell you that it is possible to remain connected to one network while scanning for other SSIDs, even if they are on different channels. (behind the scenes, it is possible that it is rapidly disconnecting and reconnecting, but if this is the case, it happens so quickly that it is irrelevant at human time scales).
With properly tuned APs, this should not be an issue. In fact, the exact opposite is often true -- the client may hang onto a more distant (or lower signal quality) radio even when a better/closer one exists. One of the really important aspects here is to reduce the power of each AP to minimize the size of the overlap region. This helps encourage the clients to roam.
Just coming back to this (since it came up on another thread)... there'e a good Crosstalk Solutions video on the same topic... at this point, Chris emphasizes how important it is to use different channels and to ensure that you are spreading the devices/channels as much as possible.
just my 2 cents worth...I think it's almost impossible to come up with the perfect setup. I set my wifi up for my samsung but find my wife's iPhone doesn't work so well. So changing things around to work better with my wife's iPhone then messes with my samsung. Different manufacturers employ different techniques to improve performance.
I remember when I had all the same router brand and models based on Qualcomm 2.4 chipsets with roaming turned on. It worked flawlessly for all devices in the house. It was the perfect solution. Maybe Qualcomm firmware worked well when you used only Qualcomm chipsets. Then I started to upgrade a few APs with dual bands and with Mediatek chipsets and latest version openwrt so my house now has a mix of Mediatek/Qualcomm chipsets and 2.4/5Ghz bands and openwrt versions. Now things don't work perfectly anymore. I am always fiddling with positioning, channels, power settings, etc..... and then throw in the different mobile manufacturers, computers, and IoT devices and it's difficult to find the perfect setup nowadays. I think there are just too many variables involved to come up with the best solution. So it's about finding the best compromise based on your equipment and end devices.
I agree with this because the world is messy. Ideal setups just aren't possible because of entropy and chaos and physics and all the other variables.
I'm decidedly not. By carefully tuning my setups (I manage 3), the performance is excellent (although not 'perfect'), even through a house with 5 APs and a fairly complex floor plan for wifi purposes. Part of my tuning also is based on the idea of reliability over speed... so I use 20MHz 2.4GHz channels and 40MHz on the 5G band. I have high quality APs (Unifi UAP-AC-PROs and LRs and a Mesh), admittedly a bit old, but fantastic hardware) placed strategically and power and channels optimized to encourage roaming as devices move around the space. All are hardwired so that the backhaul is reliable. On my own home network, I had 2 years of uptime without a single glitch (I only took them down for an unrelated upgrade of my PoE switch) -- if a device couldn't connect, it was the device at fault and usually rebooting that device fixed the issue.
So, honestly, when done carefully, wifi roaming can be high performance and low maintenance.
@eduperez is correct, unless chip manufacturers are now in the habit of just adding multiple receive ability (on a different channels) for a few milliseconds of scanning - which I doubt.
Also note these parts - which are relevant to this discussion:
The operation of performing off-channel scanning is highly dependent in terms of manufacturer implementation and configuration of the WLAN.
The client scans the off-channel APs looking for a suitable AP to connect to in case it needs to roam from its current ‘on-channel’ AP.
So how does my phone and my computer and pretty much every consumer device that is designed to be used in WiFi sta mode enable the functionality of the WiFi menu when there is already an active WiFi connection?
Fundamentally, why do most seasoned veterans in the WiFi deployment world stress how important it is to use non-overlapping channels in a multi-ap setup? If the sta devices are inefficient at scanning/transitioning across channels, clearly there must be a significant gain in overall performance when the channels are different on the aps. (Spoiler: when 2 or more APs are on the same channel, the other aps appear as noise/interference to the sta device, and even to the APs themselves, reducing snr and thus reducing throughput and overall performance and reliability).
You inquires seem as if you qualified your questions - believing that information is contrary. The information follows those best practices.
...they perform a scan. (there's more details than that, and I'm sure that's what you're asking - it gets any unhidden SSIDs it "hears" in that interval) *
So you don't interfere with other APs (as you already noted)...but how does your inquiry relate to the scanning information I provided?
This is known information - and you're semi-correct, as AP try to mitigate that to some degree. Look up the purpose of "Guard Interval" (https://en.wikipedia.org/wiki/Guard_interval).
Even in the most ideal situation, theoretically this would still result in reduced throughput.
Radio theory always gets folks when they first see some concepts - it did for me too. I hope I responded OK, some of the inquires were oddly qualified.
*- Devices also scan differently depending on if they're idle, connected/unconnected, screen off, etc. - also Androids greater than 8, as I recall - have changed their scan settings. In fact, to use advanced Wi-Fi analyzer apps, you have to now enable Developer Options to change that setting. See: https://developer.android.com/topic/performance/vitals/bg-wifi
My understanding was that using non-overlapping channels is recommended to improve throughput, as the number of clients per channel is (statistically) lower, and thus traffic is (statistically) distributed across the whole spectrum.
Also, my understanding was that overlapping channels is the recommended option to improve transition times, for the reasons I explained above.
Sorry if my reply above was snippy (I had not had my coffee yet).
Roaming can indeed work when on the same channel, but it is rarely preferable to do so, for all the reasons mentioned. The practical latency of a roaming transition is still very short when tuned well and at human scales may be nearly seamless.
I am just reading a civil discussion, about some disagreement over technical aspects...