Improved CAPsMAN Wireless Client Roaming

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”. They refuse to disconnect themselves from an AP, even though they have actually moved their location and are now much closer to another AP.  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”. So they remain “stuck” to that distant AP, even though there is a better one nearby.  So what’s the solution?

 

Add 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.  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.  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.  (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.)

 

Here is a config script which sets the level to kick a client at -80dBm. Run this on the CAPsMAN controller router, not on any of the CAPs. Obviously the exact level chosen is up to you, but I find that -80dBm is not a bad starting position for experimentation.

/caps-man access-list
add action=accept interface=all signal-range=-80..120
add action=reject interface=all signal-range=-120..-81