Hi!

I just found a solution to allow MUCH faster roaming between MT-access-points:

Just disable (R)STP on the bridge!

Such an easy thing, but that helps a lot. I never thought about this, but as a wifi-interface is down before the first clients connects, this seems to have impact.

Stril

There is other mikrotik switch in my network.Do i need to tunoff rstp in the main switch.Or just in APs

Hi!

It's just about the STP on the AP-bridge.

Setting DHCP to Authoritative also speeds up.

Hi!

Why should DHCP speed up roaming? Can you please explain?

It's just about the STP on the AP-bridge.

interesting find, but how do you go about that, when the CAP is manged with CAPsman?
Modifying the local bridge in the AP is not OK,.as the bridge gets declared/created from the datapath setting in CAPSman, isn´t it?

Source of new found information please?
Voices told me so dont count neither does, tiktok, instragram or facebook sources.

Faster roaming without STP .... is a logical statement if spanning tree convergence was the cause of the delay.

Roaming is changing the data flow from one AP to another AP, or from one WLAN interface to another on the same AP. For this to happen the client has to associate with the new AP WLAN. Sometimes the authentication can be accelerated with the proper caching parameters. The authentication is local with the AP or CAPsMAN server, this may require a respons from the RADIUS server. The client needs an IP address to continue communication. A lease renewal is not needed, as the same IP address is used. (You can see that the lease period is not reset.). Hopefully this new association is made before the old association is released.

We still have no traffic at that moment, as all data for the client is still sent to the old interface. At least one packet must be sent from the client through the network, for all intermediate bridges (switches) to learn the new path to the client. How many bridges/switches have to adjust depends on the network topology and the relative place of both AP's in that topology. Some TCP packets will have to be re-sent, if there was traffic in the pipeline towards the client that could not be delivered.via the old AP.

Sometimes the WLAN in MKT is down (if there are no clients connected). Changing the state from down to up is a state transition and a topology change of the L2 network. If spanning tree is active,then a spanning tree convergence may be needed to re-elect a root-switch and to decide which interfaces are blocked and which are forwarding. This can take several seconds with STP depending on the topology of the network. RSTP will shorten this time considerably (RappidSTP). Even more important in RSTP a transition of an edge port/interface will NOT introduce a network topology change.(Detection of a bridge port type is mostly set on automatic for edge/non-edge). RSTP is the default protocol in MKT bridges.

Not sure that STP was the cause of the delay. Certainly not in my setups with RSTP as protocol.

Turning off STP speeds up wifi connecting even if just one Mikrotik device.

Turning off STP speeds up wifi connecting even if just one Mikrotik device.

Yes it does. If the wifi interface had no other connections. The WLAN interface state transition starts a spanning tree convergence in the bridge. Just one Mikrotik device can be a network topology on its own. And normally is connected to something else, what makes STP have to select a root-switch and rebuild MAC tables and enable forwarding on interfaces.

But why did you set STP? The default is RSTP, a much faster protocol, that will not introduce that convergence. If you deviate from the default, you should have a reason.
See the wiki: "STP is considered to be outdated and slow, it has been almost entirely replaced in all network topologies by RSTP, which is backwards compatible with STP."
On just one Mikrotik device , STP protocol should be "none" indeed.

bpwl, err god of WIFI
unfortunately MT uses STP as the TAB entry and as a sub-selection of protocol mode.
My interpretation was that the OP was talking about the TAB entry so all the selections in general not the specific sub-selection variant of STP.

Perhaps when you rewrite the MT wifi documentation and code, this can be corrected!! ;-)

Yes, I'm aware of that confusion in the wording of what someone selects or disables. Sorry for not pointing that out. Wanted to warn too much for protocol STP versus RSTP.
You disable the STP protocols by selecting "none". On the other hand RSTP as protocol never has given me any roaming delay so far in a PtMP+AP's network.

Roaming that needs DHCP lease renewal is yet another mystery statement. When does it happen? Roaming that needs an IP address from another subnet is not roaming to me.

Be aware of the devastating effect of the STP protocol=STP, and the disruption of the data flow caused by it. Even if it is used upstream somewhere in the L2 domain, even by a switch of another brand, not only in the AP itself.

Protocol =STP even gives problems with a DHCP server on the bridge in MKT for WLAN. STP convergence can take extremely long for some topologies. Putting all switches in a ring is the worst I ever experienced. (6 HP ProCurve units). RSTP has the convergence prepared already, and an edge interface transition is no topology change. But if your AP is at the edge of the network why should you enable protocol RSTP? Unless it is part of a corporate network that has to be protected with BPDU guard, or is a node of a WDS, bridged or Mesh network with redundant connections that must be loop-free.

The underlying problem here is the wireless interface changing to Disabled when no clients are associated. Why does it do this? A client attaching or roaming should be no different at the STP level than plugging or unplugging a host into an Ethernet switch. It shouldn't trigger a Spanning Tree topology change. If that behaviour can't be changed it gives a problem in a network where we want the protection of STP (RSTP or RSTP+ of course). I've seen many situations where end users have inadvertently created a loop, and only STP or supervisory functions like BPDU guard have prevented wider issues.

Yes I also wonder if we can change the WLAN behavior, to be "always on". Luckily the RSTP sees the WLAN interface as an edge interface. (But that should not be the case with WDS or an active bridge connection (luckily that one is normally "on" all the time). Therefore on AP's for clients I disable the "bridge" function on the WLAN interfaces. For virtual WLAN interfaces that button is NOT in the WinBox GUI.)

Yet another point of attention with many virtual WLAN is the WLAN MAC address. When at the end of derived addresses, by adding 2 to the last HEX number, and coming to E or F, RouterOS starts assigning 02:00:00:AA:00:00 MAC address and UP. As they all use that same starting point, duplicate MAC addresses for the wifi environment are quite possible, confusing the wifi stations.

Actually my previous analogy was wrong, a new connection to a L2 switch port IS an STP topology change, it's just that this is usually over-ridden by some special fast start configuration (eg Cisco's "portfast"). A wireless LAN is more akin to an Ethernet hub, where the "network" in STP terms remains active as long as the hub's uplink is connected.

I had weird issues with my network when STP or RSTP was enabled. I was experiencing milisecond disconnects and tcp connections were interrupting. Turning stp to none and turning of stp on my main switch (Mikrotik switch os) the issue is gone.
I also had problem that traffic was not flowing at all, when rstp was turned on, on bridge interface with only one ethernet in it and cloning mac address enabled.

Don't use RSTP or STP if not required for good reason, it is not reliable !! Funny, technology known since 20 years is still unpredictable :/