I'm trying to troubleshoot an issue where "the WiFi" on a MacBook Pro (Early 2015, running macOS 10.14.6) occasionally "gets confused".
I have three different OpenWrt Access Points set up, two in the house and one in a detached office. One of the SSIDs shares the same name across all of them and I also set up 802.11r with the basics (same "Mobility Domain" value, I might have checked "Generate PMK locally" if that wasn't already the default…)
Sometimes but not always when I open this laptop up in the house after it was connected outside, it just spins and generally gets all sorts of "not working" while trying to reconnect to this shared SSID. If I toggle it over to the guest WiFi that works, and then I am able to go back to the main SSID in question without issue. But if I try to simply "stay on" the main SSID it jams up [often even if I toggle the WiFi off and back on!].
While I can't lay the blame squarely on 802.11r it is certainly a suspect. (Unfortunately the "stuck" behavior happens only maybe once a week anyway so I can't simply turn it off and prove anything right away.)
How does the 802.11r handoff work? Say I am in coverage zone A of an SSID for a while. Then I move into coverage zone B+C of the same SSID, but the signal from A is still kinda sorta visible. Could that cause problems?
Like maybe this laptop thinks that A could still help it transition and so instead of just re-authing direct with B or C it stays hanging out on the far edge of the A range spinning its wheels because the signal is so poor that nothing useful actually goes through there? Or is that a silly hypothesis to begin with?
Is 802.11r Fast Transition only recommended between AP that have significant overlap in their coverage zones?
macOS doesn't support Fast BSS Transition, also known as 802.11r. You don't have to deploy additional SSIDs to support macOS because macOS interoperates with 802.11r.
You could disable 802.11r to try it or you can set up another SSID without 802.11r that you use on your Mac to see if you still have problems and rule out 80211r.
In general FT is disappointing, roaming depends on the client. I have an iPad and it does roam but it's not great, e.g. it stays connected to an AP at -78dB instead of switching to a closer AP at -40dB. It's supposed to roam at -75dB so I guess it's right there at the edge. But I see it roam sometimes, so it sort of works. Not great for latency though if it's stubborn and tries to keep a connection to the far AP instead of being more aggressive and switch faster. Not sure why they don't implement it in a different way, e.g. if there's an AP with a stronger signal say 15dB stronger than the current connection, just roam to it, in addition to the fixed threshold.
I also discovered that if you use WPA3, 802.11r doesn't seem to be supported.
For roaming to really work you need a controller to force the clients to move to a different AP, perhaps with customizable rules. DAWN is an example but it appears development has stalled and it's not in a stable state the way it is, it needs more work.
Thanks all! Sounds like my best bet would be to do a long-term experiment and simply disable 802.11r on all APs for a while. Then at least it's ruled out and I probably wasn't getting much benefit in the first place.