Sat Jul 06, 2024 12:24 pm
It's important to keep in mind that in WiFi roaming decissions are entirely up to station (wireless client device). Whatever one configures on AP (e.g. CAPsMAN with FT) only helps station to make (hopefully) better decission. And sad fact is that some (notably a bit older) devices tend to make poor decissions. Mobility extensions (802.11 r/k/v) are fairly recent additiobs to standard and implementation follows with some delay (and, again, qusljty of implementation varies). Your Galaxy S20 is a bit aged in this respect, so I wouldn't expect it to eork as well as some more recent devices.
If a wifi device doesn't support the mobility extensions, then it behaves the way you see: it stays connected to same AP as long as possible and then reconnects to another AP (preferrably with same BSSID) ... and this is much lenghtier process than roaming/FT (hence the aversity to changing APs too often).
There's a "trick" to make station move to another AP sooner: create ACLs which reject/disconnect stations with poorer signal strengths. This, however, comes with a few drawbacks, ranging from frequent reconnections which are disturbing to the traffic, having device lingering between two APs not being able to connect to neither due to poor signal from both APs involved ... and to device simply refusing to connect to same SSID ever again due to being forcibly disconnected too many times. To make things worse, the behaviour depends both on properly selected values (not exactly trivial task) and on client device itself (again).
It's worth to point out that also in this scenario all the decissions are again made by station with exception of decission to (forcibly) drop the connection from AP's side.
Personally I'd advise against implementing this "trick" unless wifi admin knows how to thoroughly test the resulting setup to avoid the drawbacks.