Ok, we have a fairly big Wireless network that is spread out across a Mine Site. Each AP is a 900mhz Mikrotik running 4.6 code. Each AP has a 5Ghz back haul to the Wired network.
As a wireless client associates to an AP and then drives by it heading to the next AP, it will hang on to the first AP to the bitter end, basically until it looses it’s connection, then it will connect to the next AP in line.
The goal we are trying to achieve is, to either have the client drop the weaker connection sooner (and grab the better signal it’s heading towards) or we would like the AP to hand off the client to the next AP, or somehow cause the client to re-scan for the next AP.
The core issue is that clients hang on to weak signals for TOO LONG, when there’s a much better AP in their area. We want the client to either drop the weak signal at some pre-determined level (say -80 db for example) OR, we want the AP’s to communicate and push/force the client to the better AP with the better signal.
Is there ANY WAY to facilitate clients to cause them to drop weaker signals for stronger ones? In some cases we have clients that hang on to signals that are so weak, they really can’t do anything other than remain connected to the AP, and once they actually drop the weak signal and re-scan for a new one, they are fine, they just don’t seem to be able to fine a better signal, IF they are currently connected to something, no matter how poor the signal.
Thanks for the response. In my testing awhile back, it seems that the ACLs only control what you connect to, but once you are ALREADY connected, it won’t drop the signal even if it exceeds the the limit. I will test & confirm, but that’s what I recall.
So our issue is that we have a vehicle connected to a signal that goes into the high -80s to low -90s and it won’t let go and grab the new signal (which is probably in the range of -60 to -70) UNTIL it actually COMPLETELY LOSES the first signal and starts the AP search routine. We want to force it to drop the weaker signal sooner.
I don’t think the ACL will cause it to drop the signal, but I will double check. I do believe it will prevent you from connecting to a weak signal however.
Match properties that also set connection parameters
signal-range (NUM..NUM - both NUM are numbers in the range -120..120; default value: -120..120) : Rule matches if signal strength of the station is within the range.
If signal strength of the station will go out of the range that is specified in the rule, access point will disconnect that station.
How does wireless device measure signal strength, when access-list or connect-list are used ?
Reported signal level is exponentially weighted moving average with smoothing factor 50%
to avoid multiple disconnections for clients with varying signal, the signal is averaged over time for access list, so your station will be disconnected not immediately but after a few seconds when it’s outside specified signal range.
All this is well and true, but bear in mind that if you set a higher signal threshold in the access list, the client will disconnect if it finds no access points at that signal level or above. In other words, at the edges of your network, the APs will have a reduced range.
Note that Truck001 has been connected for 5 minutes at a -86 signal strengh. I tested the Access List and it will prevent Truck001 from connecting if it’s signal is below -80 as per my Acess List, but once connected it will take an act of congress to kick him off the AP.
This feature just doesn’t work. My ACL is at -70 and my client has been sitting on their for almost 12 minutes and the entire time at -90, and still no disconnect.
The ACL will prevent the client from connecting, but it wont’ boot the client after the signal threshold has been exceeded.
If registration signal<80, add the mac to acces list as deny for X seconds. This will disconect the user, and the user will reconect to the other AP. It could work.
you are correct.
Enable the wireless debug logs, to see what does it say when connecting that client.
Maybe you have left the default-authentication enabled, disable it.
Ibersystems – I don’t follow your comment “but it has a deny with signal-range=-120.-70, is the same as allow with -70..120”. Ok yes those are effectively the same, and my client is at -90, so it’s in the Deny range, so it should be denied. It IS DENIED if the client tries to connect with a signal weaker than -70, BUT, once it’s connected nothing short of moving the radio out of range will cause it to disconnect.
uldis – You say “Maybe you have left the default-authentication enabled, disable it”. As per my post: authentication=no
To repeat, this ACL WILL BLOCK radio’s when thy try to associate with a signal less than -69db (or -70 to -120) HOWEVER, if I move the radio’s togther to get a better signal, it will then pass the ACL test and authenticate the client. I move the radio’s apart until the signal is -90 and nothing happens, client stays connect, contrary to what the manual says.