On 2022-03-15, Stuart Longland <stua...@longlandclan.id.au> wrote: > On Mon, 14 Mar 2022 20:16:14 +0100 > Nicolas Goy <m...@kuon.ch> wrote: > >> I heard that controller based AP "fleet" can mitigate that by >> kicking devices that are on the "wrong" AP. But I am not sure how it >> works in practice as I only read about it and it is not any standard. > > I tried this with my fleet of Ubiquiti APs, I found my Android tablet > would always connect on the 5GHz network and refuse to even acknowledge > the existance of its 2.4GHz counterpart, to the point that when I > walked down the drive way, instead of switching to 2.4GHz, it'd simply > declare the whole network "out of range".
There are some "band steering" settings in the AP config that could make this worse (e.g. there's one which stops opaquely defined "high performance devices" from connecting to 2GHz in some cases). (For bigger setups, and I'd certainly include the 8 suggested by the OP in this, it's often helpful to disable 2GHz in most cases, just enable on some APs where needed..) > There is an option for booting clients off that have "too weak" a > signal. Basically if the received RSSI in dBm from the client is not > above a certain minimum threshold, the AP boots them off. Ideally the > client should then find _another_ AP or network, but in my case I found > the dumb client just tried again with the same AP and network, on the > same frequency. minrssi. To work properly that needs an AP design plan to ensure that minimum signal in the covered areas is up to the value you set with enough overlap between APs otherwise it ends up kicking people off their only working AP. Then they try to reconnect, then booted off again, etc. It can work, but it's easy to make things worse that way. > So yes, your mileage will definitely vary. -- Please keep replies on the mailing list.
