Hi everybody!
 I've configurated CAPsMAN v2 between CloudRouterSwitch109 and RouterBoard951Ui, os ver.6.35.4.
The problem is when client moves from one room to another, his devices stays on first AP with bad signal -76db, while second AP have better signal -45.
what I should to do for seamless roaming, any advice??

Add an access-list rule which rejects when the signal is too low.

Have a look at our article :
https://blog.linitx.com/howto-improved- ... t-roaming/


Nick

what I should to do for seamless roaming, any advice??

Your roaming should already work seamlessly. It's client who always decides when to roam, and RSSI (aka signal strength) is not the only parameter that it takes into account when making roaming decision.

I suggest you searching the forum for additional info on how WiFi roaming works.

Add an access-list rule which rejects when the signal is too low.

Have a look at our article : https://blog.linitx.com/howto-improved- ... t-roaming/

I suggest you NEVER do that. Forced kick-off will make roaming experience significantly worse for a lot of client devices.

Seamless roaming will only work prperly with these vendors Meru (now Fortinet) and Extricom. But use a single-channel infrastructure. Roaming is not anymore a decision of the client with these vendors.

Also Ubiquity offers a seamless roaming mode, but this one is only recommended on low occupied noetworks, because Ubiquity doesn't do any Airtime coordination.

All other vendors simply offer a Fast Roam capability, which must be supported by the client. If the client doesn't support fast-roam you'll have to use the above mentioned vendors on order to get seamless roaming.

Seamless roaming will only work prperly with these vendors Meru (now Fortinet) and Extricom. But use a single-channel infrastructure. Roaming is not anymore a decision of the client with these vendors.

It's not a decision of AP either, since in SCI scenario there's no roaming as such at all. SCI is not about roaming, but rather about making multiple radios works a single huge (distributed) access point. That approach has both its pros and cons. And, by the way, as far I'm informed at least Meru is dropping SCI support in new product- no ac-capable product will support SCI.

I am well aware of the fact that SCI presents a single AP to the client. I didn't want to make it too complicated.

I am running several infrastructures with Meru and 802.11ac in SCI. It works damn well. Customers are very happy with it.
A Meru representative never told about anything like dropping support for SCI on Meru products. SCI is the USP of Meru.

andriys the access list rule should not cause any problems, the delay is tiny, and most clients will not notice. You are right that client decides to roam, but they mostly do it badly, and hang onto bad connections much too long.

andriys the access list rule should not cause any problems, the delay is tiny, and most clients will not notice.

In fact they do cause major problems with some clients. I did an extensive testing before deploying a small CAPsMAN based network here. Most (if not all) Android clients I tested behave badly when using forced kick-off- a tiny barely noticeable delay when Android client roams itself becomes a huuuuge couple of seconds connection drop after each forced kick-off. Windows and iOS clients are much less sensitive to forced kick-offs.

Some client wifi card drivers offer to set the roaming aggressiveness level. You should set it to high value instead of middle.

andriys the access list rule should not cause any problems, the delay is tiny, and most clients will not notice.

In fact they do cause major problems with some clients. I did an extensive testing before deploying a small CAPsMAN based network here. Most (if not all) Android clients I tested behave badly when using forced kick-off- a tiny barely noticeable delay when Android client roams itself becomes a huuuuge couple of seconds connection drop after each forced kick-off.

Modern Android versions (5.0+) are quite good at figuring out when to switch APs themselves, btw. Maybe with older versions this is a problem, but 5.0+ even does switch to 5 GHz aggressively. I have some OS X clients and their roaming behavior is much more conservative.

I don't think fiddling around with access lists is worth the hassle. Maybe MikroTik could add some kind of band steering, but unless this happens I'm already quite satisfied with the behavior of modern wireless clients.

Modern Android versions (5.0+) are quite good at figuring out when to switch APs themselves, btw.

Indeed!

I don't think fiddling around with access lists is worth the hassle.

And this is exactly what I'm repeatedly trying to say in this and in numerous other threads on this forum.

Hi everybody!
 I've configurated CAPsMAN v2 between CloudRouterSwitch109 and RouterBoard951Ui, os ver.6.35.4.
The problem is when client moves from one room to another, his devices stays on first AP with bad signal -76db, while second AP have better signal -45.
what I should to do for seamless roaming, any advice??

Reduce the signal strength of your AP's to nothing more than what's sufficient for each room respectively.

correct, but does not deny that roaming support according to 802.11 k / r / v is not supportet at the moment.