Mikrotik : Constant ~1sec drop when roaming. We tried tried RSTP off/on, ROS 7/6.49.2, numerous resets and other tweaking. Constant ~1sec drop.

/caps-man access-list
add action=accept allow-signal-out-of-range=6s client-to-client-forwarding=yes disabled=no interface=any signal-range=-80..120 ssid-regexp=""
add action=reject allow-signal-out-of-range=6s client-to-client-forwarding=yes disabled=no interface=any signal-range=-120..-83 ssid-regexp=""

Interesting article and I would be happy to see these improvements.
One other thing that is different that I have already suggested in the past but didn't see any action except the very first days of discussion is the fact that ubnt controller is pushing the parameters to the APs and if we loose for some reason access to the controller the APs are still working without collecting statistics. Even if you reboot them all settings are there working fine.
In the MikroTik controller if the client loose communication for a few (5-6 I think) seconds, it stops working waiting for the controller to "control" it.
Of course that would only be possible with the local forwarding option but I believe that most traffic hungry setups are done with local forwarding else they are way slower!

It would be an interesting option and then we could also move our controllers to the cloud as well for our customers!

Klembord-2.jpg
.
.
To my experience this will not let you return to this AP for 6 sec, after you have been kicked out, even if your signal is now OK.
Even if you set this to 1 sec, there is another cache for a short delay that says "banned(last failure ...)"
This is a problem if the AP's are in adjacent rooms and people are going back and forth in the 2 rooms.
So "flapping" from one AP to another will create reject periodes.
The same seems to happen with a client device, trying to do band switching to 5 GHz on the same AP, but failing on signal strength.

Klembord-3.jpg

Did you add this for improved roaming?(fine tune the value to your liking)

Code: Select all

...
add action=reject allow-signal-out-of-range=6s client-to-client-forwarding=yes disabled=no interface=any signal-range=-120..-83 ssid-regexp=""

/caps-man rates
add basic=18Mbps name=rates_5g supported=18Mbps,24Mbps,36Mbps,48Mbps,54Mbps
add basic=18Mbps name=rates_2g supported=18Mbps,24Mbps,36Mbps,48Mbps,54Mbps

From my experience it's much more efficient to set a standard minimum data rate of 12 or 18M, so clients are at least aware of the limits, and will try on purpose to find nearest AP more aggressively

Did you add this for improved roaming?(fine tune the value to your liking)

Code: Select all

...
add action=reject allow-signal-out-of-range=6s client-to-client-forwarding=yes disabled=no interface=any signal-range=-120..-83 ssid-regexp=""

At best it's not any better, at worse in your dark spots clients get kicked out and will try to reassociate to same AP.
From my experience it's much more efficient to set a standard minimum data rate of 12 or 18M, so clients are at least aware of the limits, and will try on purpose to find nearest AP more aggressively

Code: Select all

/caps-man rates
add basic=18Mbps name=rates_5g supported=18Mbps,24Mbps,36Mbps,48Mbps,54Mbps
add basic=18Mbps name=rates_2g supported=18Mbps,24Mbps,36Mbps,48Mbps,54Mbps

But anyway that's not the point here.
The ~1sec drop is not related to a critical loss of signal, and i'm not sure it is really related to strict-sense roaming either...
It's more like, in the Mikrotik setup, the AP, upon association, waits ~1sec before it starts forwarding data.

The 1sec "audio drop" occurs just after android client shows successfull association to new AP, not before or during the operation, that's the thing...

Might be related :
- to the lack of "BSS transition" ? i still don't know exactly what it is
- to some delay in Mikrotik APs firmware ?

From my experience it's much more efficient to set a standard minimum data rate of 12 or 18M, so clients are at least aware of the limits, and will try on purpose to find nearest AP more aggressively

Yes, I do this as well. Difficult to tune, and I miss somewhat the "allow-out-of-range" equivalent. Missing AP beacons will disconnect the client, maybe too soon.

And the day that Caps-Man can control a good radio... that can support MU_MIMO and keep clients connected... I will bid farewell to other manufactures...

I tried exactly like that and than i had droped pings not to mention some clients would randomly get disconnected, think its some power saver on wlan cards and it cant go into lower rates and gets disconnected with full signal..

One other thing that is different that I have already suggested in the past but didn't see any action except the very first days of discussion is the fact that ubnt controller is pushing the parameters to the APs and if we loose for some reason access to the controller the APs are still working without collecting statistics. Even if you reboot them all settings are there working fine.
In the MikroTik controller if the client loose communication for a few (5-6 I think) seconds, it stops working waiting for the controller to "control" it.
Of course that would only be possible with the local forwarding option but I believe that most traffic hungry setups are done with local forwarding else they are way slower!

/radius
add address=10.39.1.51 secret=xxxxxxxxx service=wireless
/interface wireless security-profiles
add authentication-types=wpa2-eap mode=dynamic-keys name=EAP_AP supplicant-identity=MikroTik
/interface wireless
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX disabled=no frequency=auto mode=ap-bridge security-profile=EAP_AP ssid=Mikrotik wireless-protocol=802.11