Good morning,
I’m really glad, that mikrotik made and released CAPsManager. But I think, CAPsManager should support Roaming between networks, something like it has UBNT and UniFi.
Please, add this in new versions. I think, I’m not alone, who want this.
Regards
Blažej
Do you mean as you move from one AP to another if they have the same SSID + Security (which CAPsMAN manages) then it should auto switch to the new AP?
Because this already happens.
And is usually more-so governed by the client device rather than the AP.
If you mean another type of roaming, please explain it more clearly.
Yep, that’s already happening with almost any kind of APs available these days. However in this case a brief disconnect happens when client roams from one AP to another, which is a no-go for some applications like VoIP.
I believe blazej44800 asks for a so called seamless/zero-handoff roaming, in which case disconnects either do not happen at all, or (at least) are significantly shorter. It used to be only available in costly solutions (with ruckus being the most affordable among them), but now Ubiquity claims that starting from v3.1.x UniFi supports it as well.
There is one more problem with “seamless” wi-fi.
If phone connects to ap1, then phone owner moves to ap2, but phone is still connected to ap1, with bad signal.
Ubiquty use centralized managment to drop clients from far away aps.
It would be nice if capsman could do the same thing.
You already can disconnect client with bad signal but it will not ensure seamless roaming to next ap.
I understand the request and it is a good one, but just wanted to note, that you can already configure access list to disconnect client with bad signal, and the client will then reconnect to the nearest AP
The client will decide itself where to connect. And it will not be seamless. I experimented a bit with client disconnection in such cases and can tell that you can easily disconnect the client that does not have better connection option to choose. Mobiles are moving and even they are in good area they can have temporarily bad signal. To disconnect them in this case is really silly because a second after the signal is good again. So what now?
Vote for this too.
Really like Mikrotik products and it’s sad that ubnt already implemented some alternative solution while we don’t have one.
But at least I hope it’s starting to appear and developing CAPsMAN is a really good step.
I also please let me agree with this opinion.
I’m glad I also and will be able to build a roaming environment utilizing the capabilities of CAPsMAN.
Best regards.
Hi,
I vote for this too!
With regards,
Kuba
Here need it too. CAPsMAN is a great feature but lacks of 802.11r or similar solution.
CAPsMAN+usermanager+ovpn+dhcp+server+hotspot are all-in-one machine great wifi controller that lacks “native” seamless roaming.
Hello,
I think we don´t need to worrie about seamless/zero-handoff, ubnt controler did not had on first versions, soo i think its a question of time for capsMan to have it 
That’s not even close to the capability of a fully managed zero handoff roaming situation. Zero reauth, virtual bss per client moving from ap to ap.
The amount of misinformation out there is astonishing!
First of all - roaming is always a client decision; When to roam, what AP to roam to, what band (2.4 or 5) to prefer.
The process is simple:
As you can see, at no point is any AP doing anything to make the client roam.
What OP is talking about is Meru’s Single Channel Architecture, which was copied by Ubiquiti with Zero Handoff. In simple terms, the AP dynamically creates a virtual access point for each associated client. The infrastructure (Meru controller) then moves this virtual access point to different APs depending on where it (controller) wants the client to be associated with. Essentially, it is fooling the client into thinking that there is no other AP, and therefore never actually roams. SCA/ZH have their advantages and disadvantages, but nowadays client devices have improved their roaming algorithms so much that the disadvantages far outweigh the advantages. Even Meru is moving away from that architecture.
802.11r/11k are standardised protocols which have been created to assist in client roaming. Note the use of the word assist, as it is still a client decision. 11r simply avoids the long trip to the RADIUS server whenever there is 802.1x authentication involved while 11k tells the client about neighbour APs so the client does not have to waste a lot of time scanning the air for new APs.
VoIP works fine even today on any standard WLAN, as long as it is set up properly and you use good VoIP handsets.
To see an example of a really bad roamer you don’t need to go very far. a MikroTik wlan interface in Station mode will not scan or roam until it completely loses connectivity from the AP. This is called reactive roaming and no ‘real’ WiFi clients (phones, tablets, laptops) behave this badly.
nb: I say badly but the reality is that MT is designed as a fixed location PTP/PTMP endpoint so should never roam
First of all - roaming is always a client decision; When to roam, what AP to roam to, what band (2.4 or 5) to prefer.
FALSE
AP can kick a client if weak signal, max clients reached or member of load balancing group forcing roam.
nb: I say badly but the reality is that MT is designed as a fixed location PTP/PTMP endpoint so should never roam
FALSE
I have 44 radios (88 SSID’s) connected to a single CCR1036 (capsman+usemanager) and i can have a perfect skype conversation between all SSID’s roaming seamless in 2.4 and 5GHz.
I liked the term “reactive roaming” you have said before. I understand your concept and I’m sure there are better formulas to roam but mikrotik works very well and for a lot less money than any other solution .
Ap can kick. But then client decides autonomly where to try to connect.
And that is where the confusion begins. By kicking off the client (a deauth request), the AP is simply telling the client to disconnect from it. The client may decide to reconnect to the same AP or try another AP, based on it’s association algorithms.
Careful using the term load-balancing. Most enterprise-grade vendors which have AP load balancing or band-balancing do their ‘balancing’ at the moment of association. Once a client is associated, LB/BB never kicks out forcefully as that will trigger an emergency/reactive roam.
Of course, since it’s a client-driven process and there are no standards defined on the roaming algorithms, how quickly the emergency roam takes depends entirely on the clients.
Good for you, it just means your client devices are very good roamers.
Read my post again, I specify that using a MT device as a station results in poor roaming, because MikroTik is not designed to roam quickly and therefore has practically zero roaming processes. It simply waits until the signal is too low, disconnects, looks for new APs, and joins strongest signal.
Also, Skype is designed to work in the wild west internet, so has very good adaptive algorithms and would probably work well even if used over a MT in station mode. Try doing the same with SIP or an old console-based application or a MS Access database.
If it works well for your application, go for it. The point of this discussion is different. OP asked that “CAPsManager should support Roaming between networks” and a lot of misinformation ensued (including yours I’m afraid), so I wanted to set the record straight on how 802.11 WiFi works.
I’d be interested as well
Hi,
Controlling clients with access list prevents bad signal clients and low bandwidth.
The biggest difference with seamless roaming, multiple AP and unifi is the that clients see only 1 AP and 1 mac-address.
This prevent Apple device to constantly jump, register, disconnect over detected APs when in idle mode. This completely kills the bandwidth in a multi-AP environment…
Best Regards,
Julien
Not really. Roaming is the way 802.11 is designed to work!. In fact, Apple devices tend to be the best behaved devices on a WiFi network and their roaming behaviour is well documented - http://support.apple.com/en-us/HT203068