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.
I assume as the number is increased the problems should become less problematic? like 200m would be less likely to cause problems than 100m and if you make it 10m it'd be very problematic
Yes, although the clients also need to accept what they're presented with (that's why I referred to "long distance directed links" - as this means both peers are tuned the same way, without random clients being part of the story).
I played with it and yes, clients are e.g. not so amused when the AP disconnects them and they don't have what they see as a better alternative. Actually that's something one can expect. However, e.g. Disconnect WiFi STA (clients) based on their signal levels (also mentioned in that post) provides some mechanisms to avoid problems in some ugly situations.
I think the distance optimization controls timing. if you have a multi km link the AP needs to wait for ACKs due to the speed of light. if you set it to say 100m then anyone beyond that distance will have trouble connecting because they won't ack packets fast enough. this is a way you can keep people from connecting at longer distances. for example I have an unencrypted guest Network and want to keep people across the street or in neighboring houses off the net.
but power saving might also muck with timeouts for example and so too short of a distance might cause mobile phones to fail to maintain a connection or some similar issues... I'll have to play with it and will report back. also remember it's total propagation path length... so if you are connecting via signals reflecting off walls, down a hall and through doors the propagation path might be considerably longer than straight line distance.
To me, it looks as if my dual band STAs lose 5 GHz AP connectivity, switch to 2.4 at the next, then "recover" to 5 only after some time of good signal strength. But I have to make more tests.
The Nintendo Switch does not seem to roam, atleast not with hidden SSIDs.
Hidden SSIDs help keep picker menus cleaner, but don’t add significant security, in my opinion. As you’ve noted some clients aren’t as robust with hidden SSIDs.