Hidden SSIDs just make debugging more difficult, they don't add any kind of security (actually the reverse is true, as roaming clients will leak your hidden SSIDs when they're not in range) as it's trivial to 'unhide' them by simply sniffing.
indeed setting distance optimization to 60m caused problems and even 200m cause my mobile phone to flake out, probably due to power saving or similar. this even though my house is less than 60m end to end and there are 3 APs.
Update: Whether SSIDs are hidden or not does not seem to make a difference in my case: The Nintendo Switch will simply not roam - no matter what. And I think the Apple devices (at least iPhones) were unhappy about the gateway not responding to ICMP ECHO. Plus, I had a bad config in one of the APs which doesn't ron OpenWRT.
Without playing with any settings impacting handoff, even WiFi Calling performed rather nicely. Moving very quickly between the three APs led to short interruptions, though.
also ime default settings + dumb_ap + vlan bridge works rather good/universally and short interruptions on roaming are better than "not working at all with some devices".
k.i.s.s.
this should be the default setting (see option legacy_rates)
Yes I changed settings from the defaults; however then I attempted to revert do defaults. Not sure where you want me to check option legacy_rates, but on OpenWRT: WiFi /etc/config/wireless it says that it's a common option that defaults to 1, which is supposed to mean that legacy rates are supported?
I mean Facetime calls without interuption while I move around in house and change AP's. Phones (I only have iPhones and iPads) tend to roam worse and "hang" on 2.4GHz AP's for much longer. They just snap on 5GHz 802.11ac AP's quicker.
SSID's and passwords must be the same. I have four Archer C7's acting as dumb AP's and it works very well. Do not hide SSID's.
I noticed that tendency to "latch" onto weak AP's is lower when "legacy b rates" is not enabled. I have no clue what it does except that it hurts my roaming.
Legacy b rates enables 802.11b rates including rates down to 1Mbps. This allows your device to remain connected at greater distances because the lower speed rates will operate over much longer distances (at low signal to noise). This means your device will tend to be able to hang on distant nodes much longer, at the expense of massive reductions in throughput for all devices.
The same issue applies to 5GHz, it has shorter range, and hence you will more rapidly roam between the stations. You can handle this by either adjusting down the power of the 2.4GHz radios, or adjusting the allowed rates to even higher rates... causing your device to disconnect more quickly.
And how quickly do you move? Have you made a test where you almost run?
But it sounds a bit as if e.g. WiFi calling with your iPhones could behave less optimal, and that's what I can observe.
I also find my OpenWRT Archer C7 V5 very enjoyable as an AP which manages my VLANs and, for now, runs minidlna. My OpenWRT R6120 also behaves well, within the range of its specification.
Would you be willing to share some details of your configuration? I re-read Why You Should Disable Lower Legacy Data Rates and it suggests setting 12 Mbit/s as the lowest basic rate, but what are you using? And how exactly is that configured in /etc/config/wireless?
I have come to the conclusion that I'd like to try it, but I'm not even sure how I would identify a problem in my configuration. I'd find it helpful if you could provide some details.
It seems like the "basic_rate" parameter lists rates that clients must support (all of them) in order to connect. "supported_rates" lists rates that clients may use after they've associated. So supported_rates must list all the basic rates, but can list more rates as well.
The 802.11a standard for 5 GHz never included "b" type modulation and rates. The minimum rate on 5 GHz has always been 6 Mbps, the same as the lowest "g" modulation. It is unclear what if anything the legacy_rates setting could do on 5 GHz.
also: the lowest basic_rate is used for multicast/broadcast (arp/dhcp) aswell as for the beacons. legacy_rates 0 removes the 11b rates from basic_rate but not from supported_rates so a client can make its roaming decision based on the signal strength of the beacon/basic_rate but is able to use the lower data-rates as a fallback.
i am unclear what the implications of restraining both are.
I read somewhere that beacons are supposed to be sent at the lowest basic rate, but that multicast/broadcast could be sent at the highest basic rate... I don't think this is actually what's done though, my impression is the lowest basic rate is what's actually used for multicast.
When I disable everything below 12Mbps things work fine on my home network, and clients roam a little more quickly. This is useful because when running WRT32X as my APs I can't control the signal strength (it's locked in the hardware to the max output) so by controlling the rates it forces my devices to move to their closest AP more quickly, otherwise they tend to stay locked even out to about the middle of my front yard.