What would happen if each AP uses the same channel? Does it affect roaming, or are you suggesting to have separate channels "only" because it improves throughput in the absence of other networks?
Is there nothing that a controller could know / do better than the client, unless I have dozens of clients?
I'm sure it could do better, but this functionality is only available on proprietary systems. And it would be rare to see major problems without dozens of clients. One thing you might do is eliminate some of the slower rates, make sure to disable all 802.11b legacy rates, and maybe even disable the 6 and 9 Mbps rates, this will force roaming earlier.
It would dramatically reduce effectiveness of the whole system, use separate non overlapping channels.
Which effectiveness? Data throughput or client roaming? (Because if you're referring to data throughput then I believe you're assuming that there's no foreign WiFi disturbing the channels.)
Client roaming algorithms vary by vendor but I believe they often prefer a different channel to the same channel. So both, maybe?
Thank you for pointing this out! I just found Why You Should Disable Lower Legacy Data Rates based on your hint. Sounds promising. I'll have to play with /etc/config/wireless, right?
Yes, basically the higher you set the minimum rate, the closer the device will have to be to maintain a connection. When there are multiple APs you want to only use higher rates and force roaming rather than stick to same AP with lower rates.
According to SmallNetBuilder: How To Fix Wi-Fi Roaming, it seems as if 802.11r support would be beneficial (for clients which support it)....
There's kind of minimal support in general for 802.11r but if you're using WPA2-PSK it's just a checkbox to enable it... so you could try. Apparently it helps with Apple products, and it can prevent some older devices from working at all.
Low power on the AP's is key as mentioned.....
You can also lower the beacon interval slightly, if snappy roaming is preferable to a decrease in throughput across the board.
Doesn't 802.11r require any hardware / driver support?
Good to know, thanks! I will play with it, assuming that the decrease in throughput is relative to the connection speed, which should be good enough with small distances between access points and clients (if handoff works as expected).
it does require software, wpad/hostapd supports it, and like I said it's a checkbox if you're using pre-shared keys.
On the client, yes it requires support, and many many clients don't support it. Some to the point of being unable to connect. Basically for a few more years I think it's unlikely to be a good idea to enable 802.11r
It's really that the beacon takes up airtime, so that airtime doesn't get used to transmit data.
First of all, I'm still trying to find out how to disable rates. For openwrt, would /etc/config/wireless be the right place? Any UI, any other platform?
Unfortunately, my AP does not seem to be supported by openwrt, ánd I'm trying to avoid wrong investments. Therefore I'm still collecting material and trying to play with what I currently have.
Am I right in assuming that "disabling WiFi connection features" such as rates is "more natural" than having the AP disconnect based on criteria? I would assume so because then it's still completely a client decision, nothing forced by the AP.
There are a few approaches to have the AP disconnect: ASUS offers a "roaming assistant" based on configurable signal strength. For OpenWRT, there is angry_wifi.sh and, more sophisticated, Disconnect WiFi STA (clients) based on their signal levels whcih considers SNR, something I find interesting.
What about 802.11n only for 2.4 GHz? Is that something that one would expect to come close to disallowing 802.11b? (There are no b/g clients left.)
Yes, you should definitely run in N only mode. The signal strength based client dropping is also useful. It lets the AP make use of its own info about how loud the client is. There's nothing "purer" about making the client do the work, particularly for devices with basically braindead client algorithms.
For OpenWrt check out the basic rates and supported rates parameters in the wireless config, see the wiki for details. To get started in Luci you can go to the SSID and click advanced and deselect the allow legacy rates, then in the wireless config you can cut out even a few of the remaining lower speed rates.
I was playing with a TP TL-MR3020 V1.9 which was collecting some dust, installed OpenWRT, looks good. But it's not suitable as my target device; I just conducted some feasibility tests.
Now I found out that the new device I have on my mind would use the ath10k driver which always reports a fixed TX rate and I'm wondering whether that would affect the logic of not allowing low transfer rates?
I was seeing over 500 mbps throughput in both directions on QCA4019 and QCA9888 yesterday using -ct drivers, so I’d be surprised if there is a general driver issue.
Thank you for sharing. In fact, I saw a review of a QCA8075 (I think) based product claiming it transmits only 6 mbps and I believe the reviewer was misled by the mentioned driver bug. According to the ath10k page, information in /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats should be correct, but somwhere else, the driver indicates a wrong rate of 6 mbps regardless of the actual tx rate (amd I'm not even sure where the wrong reporting can be found).
In my scenario, I want to follow the suggestion of disabling low rates, for which the best place would probably be basic_rate and supported_rates in /etc/config/wireless. So since ath10k somewhere indicates the wrong rate, I was wondering whether that should affect my buying decision or not.
OpenWRT's LUCI, at least for 18.06.2 and later, offers an advanced setting "distance optimization" that you didn't mention. Is it also worth testing whether it is helpful?
I'm asking because while I guess that STA and AP will not "negotiate" a "distance" but rather have their own ideas of how well they receive the other party's signal, I'm still looking for a mechanism where both parties actually "agree" on their connection's quality. (I'm aware that "distance" is derived from the signal, but at least the value is also shown in wifi analyzer apps.)
The distance setting is actively harmful, unless you know exactly what you're doing and need it for really long distance directed links (measured in multiple hundreds of metres or dozens of kilometres). It's best to leave it alone (unset) for 'normal' uses.