(But this can be used as a security feature as it now limits the receiving range of your Wireless System on the edge of your building, thus reducing the distance they can be connected from.) The only downside is that if a client device is leaving the building, they will be forcibly kicked and have no other AP to connect to. The client, now having been kicked from the AP will be forced to re-scan and (hopefully) find another AP much stronger and connect to that one instead. So what’s the solution?Īdd a couple of Access-List rules to the CAPsMAN controller and you can then make the AP forcibly disconnect the client once it has reached a certain signal level. So they remain “stuck” to that distant AP, even though there is a better one nearby.
#MIKROTIK CLIENT ROAMS DHCP SOFTWARE#
The client software seems to hang in there for dear life, despite having a very poor and low speed of connection, but it seems to decide, “some connection, no matter how bad, is better than none at all, but I will not check to see if there are any other APs that are stronger”. They refuse to disconnect themselves from an AP, even though they have actually moved their location and are now much closer to another AP.
CAPsMAN is a very useful method of setting up a large number of APs (CAPs) in a building, but how can you help a client to roam better? The problem is that clients can get “sticky”.