LinITX Blog Ubiquiti & MikroTik Wireless Networking Experts
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
Does this kick the user or just not allow new users with signal worse?
It will kick existing clients off when their signal goes below the threshold.
In my experience an access list is exactly what it’s called: it prevents access from new devices with signal lower than the figure set. This means that the problem at hand, that of a client holding on until signal is extremely bad instead of hopping to a new stonger AP/signal is NOT SOLVED with this method, however it helps a little if you have many AP’s with better signal in the same area, however the client will usually connect to the strongest signal anyway so not really relevant.
LinITX have you ever even tried this as in my experience your comments is wrong.
The problem is that the client is in control of making the decision to drop the connection or not. If the client thinks the signal is strong enough, it could remain connected even though there is actually a stronger AP nearby. Device drivers are becoming better, devices are becoming better but there is always going to be one old client somewhere that refuses to let go of that 1Mbps signal and stays connected whatever! Therefore by using the access list suggested, the weak client will be removed from the AP they are connected to in real time. Thus forcing it to scan for a better AP. If there are no other APs that are stronger, it will remain disconnected. The access list is scanned regularly by the controller and the decision to remove a connected client or not is done near continuously. It is not actioned only at the time of the client’s initial connection time. Therefore in the scenario stated, a site of multiple APs, this additional piece of code is very effective indeed. It is also worthwhile considering the removal of the lower data rates and modes (such as 802.11b) to further improve wireless performance.
Yes, we have tried this. It works. The Access List is scanned approximately every few seconds and if a client is already connected with a strong signal, but then worsens over time, when they fail to meet the level set (e.g. 80dBm) they are disconnected at the exact moment they fall below the set level. Access Lists are NOT applied at connect time ONLY. They operate continuously.
This can be done, no matter if we are using CAPsMAN feature or not. We did this pseudo roaming on old RB133 long time ago, and yes, it works 😉
Can this command be used if I am running CAPsMan and CAP on the same device (CRS) please? The comment above says only run on the CAPsMAN device.
Thanks.
Regards,
John
I was saying that you only need to install the script on the controller as that is where the setting will need to go, so as to control all the CAPs. If the CAP is ALSO the controller, then yes, you install it on that one device.
/caps-man access-list
add action=accept interface=all signal-range=-80..120
add action=reject interface=all
This should work the same, seems like there’s passthrough on the rules, so as long as the accept’s first it’ll help.
Cheers 🙂
hello. why is the range to 120 ? this could go from minus to 0, no ? thanks.
Thanks for your question. We advise setting it that high because the command allows you to set a maximum signal strength as well. Since our aim is to set a minimum threshold only we set the maximum to a number so high that it would not be attainable and therefore does not affect the operation of the unit in practice. Think of that line as basically saying “accept everything above -80db” because in the real world you would never receive a signal stronger than 120db. Hope that helps.