ROS wireless feature request Wireless-Access-List

I have discovered a serious problem with the Wireless Access List.
If a Wireless Access-List uses the "Signal Strength Range", it will create all kinds of problems.

I would like to see anew optioncheck-box in this setting "Do-Not-Track-After-Initial-Connection"

问题是,是什么信号强度范围哟u set the Access-list at, will result inclients getting disconnected, then re-connected, then disconnected - - - over and over and over again．

The reason why clients keep bouncing off and on is:
Upon initial wireless connection, the wireless connection rate is normally a basic rate or slower rate. All wireless cards in the AP and in the Client devices use more transmit power and have greater receive signal sensivity - resulting in a stronger signal strength. This may be a good enough signal strength to pass through the Signal Strength Range.
The problem is that after the client is connected, the connection rates will begin to climb to faster/higher connection rates. All wireless cards in the AP and client devices have a lower transmit power and a lesser receive sensivity at higher rates. Thus after the client rates climb, the Signal Strength Range can be out of range and the client is auto-disconnected.

This pattern of connect, rates begin to climb, then disconnected creates horrible problems. Clients are constantly getting kicked off the wireless network.

A new option to disable tracking on wireless connection signal strengths in the Wireless Access-List will prevent this.

I currently have several hundred clients connecting and disconnecting between my many access points facing into an area.

I think we really need this option to help solve some serious problems with the way Signal-Strength-Range currently functions.

North Idaho Tom Jones

Interesting. I've observed clients getting kicked off and on, over and over, and it was interference on the 2.4Ghz band. Are you seeing this under 2.4Ghz or 5Ghz?

Interesting. I've observed clients getting kicked off and on, over and over, and it was interference on the 2.4Ghz band. Are you seeing this under 2.4Ghz or 5Ghz?

Both 2.5 & 5 GHz ( hundreds and hundreds and hundreds ).

I posted this issue to the Mikrotik forums about a year ago , and heard nothing back. As a Band-Aid fix, I was modifying access-lists and scan-lists. When you have a hundred APs and 1,000 clients, this is way more than impossible.

As it is, I consider the wireless access-list signal required signal strength feature totally broken and not even close to useable in any manner.

No matter what setting the wireless access-list required signal strength settings are at, it will always create serious problems which will produce frustrated and upset customers.

All wireless connections are stronger/better upon initial connection. -and- All wireless connections are weaker when connection rates begin to climb after initial wireless connection.

Here is evidence of what I am stating
Pick any wireless product (pick any ...) - the results are all the same...

Random pick --> Mikrotik Groove 52 ac
Connect rate Transmitted power dBm Receive sensivity
梅格26 -93
54 Meg 21 -78
MCS0 26 -93
MCS9 19 -69

When a Mikrotik Groove 52 ac connects to another Mikrotik Groove 52 ac at 6 Meg then rate-shifts up to 54 meg,the signal strength will loose 21 db．
When a Mikrotik Groove 52 ac connects to another Mikrotik Groove 52 ac at MCS0 then rate-shifts up to MCS9,the signal strength will loose 31 db.

My point is, that no matter how you use wireless access-lists required signal strengths, it is going to fail and create wireless network problems.

There needs to be a new option to not track after initial connection．

North Idaho Tom Jones

That's because depending on the rate it will transmit at different powers when using default tx power or card rates setting.
If it were to transmit at full power at higher rates it would transmit a distorted signal or it could even damage the output amplifier of the card.
Maybe there are safeties in place nowadays to prevent damaging the hardware, but I clearly remember back in 2006 we had a lot of 'burnt out' cards (mainly wistron cm9) due to high tx power being forcefully used on high rates.

Why don't you use fixed tx power? With fixed power you get the same signal regardless of the rates. But you need to be careful to not use too high tx power otherwise higher rates won't work properly (or as I mentioned you might even damage the card).
And maybe even use fixed rates (with a basic 6mbit as fallback)?

I do that on all my links and the signal level is always flat within 1-3dB fluctuation depending on weather conditions etc.And also with fixed rates the performance and latency of the link is also more stable and predictable.Of course in case of interference a fixed rate setting may cause a lot of disconnects.
So constant monitoring is a must in such configurations.

Granted I do this on ptp links only. I don't have multiple clients per AP, only backbone links.
So now that I think of it, fixed rates won't help you in your case since you are talking about ptmp links.

But fixed tx power may solve the issue you describe.

Cha0s

I understand how and why wireless connections rate-shift and rx/tx db levels at various rates.

What I am saying is "There is a problem with Wireless Access-List required-signal-strength".

For it to work as is, there could only be one wireless connection rate with absolutely no rate-shifting. If the wireless world was only 1 and/or 2 meg connections then it would work. But with modern protocol rate-shifting, anybody using this feature is doomed to failure and problems.

I would assume the original intended function of this feature was to prevent weak connections and to disconnect weak connections. Well you can't properly do both at this time using the current Mikrotik ROS wireless access-list required-signal-strength settings. To properly accomplish this, there needs to be a new option "do not track after initial connection".

With a new feature "do-not-track-after-initial-connection", you could then do something like this:

Rule # 1; (To connect) required signal strength range 0 to -55 db (Do-not-track-after-initial-connection).
Rule # 2; (Disconnect) auto-disconnect at range -86 db or weaker

With my requested feature/option, everything should work very well.
As it is today, it is failing and constantly disconnecting clients while injecting all kinds of wireless network problems into the wireless network.

North Idaho Tom Jones

Have you at least tried setting 'all-rates-fixed' tx power on the clients to see what happens?

Thatshouldsolve the issue you describe since they won't change their tx power when shifting through rates.

Don't get me wrong, I understand what you ask and it sounds reasonable.
But I assume you want to solve the problem at hand, sooner rather than later since you have clients complaining.

Unless you want to wait until Mikrotik decides to implement what you ask

Have you at least tried setting 'all-rates-fixed' tx power on the clients to see what happens?

Thatshouldsolve the issue you describe since they won't change their tx power when shifting through rates.

Don't get me wrong, I understand what you ask and it sounds reasonable.
But I assume you want to solve the problem at hand, sooner rather than later since you have clients complaining.

Unless you want to wait until Mikrotik decides to implement what you ask

There are several inherent problems with all-rates-fixed. Even if all transmit rates were locked in at the same transmit power you encounter the following issues:
#1 - As connect rates increase after the initial connection is established, the AP receive sensitivity at higher rates will still get worse.(Again a problem)
#2 - You are decreasing the default transmit power for all lower speed connection rates.(Again a problem)
#3 - With all TX power rates fixed, at the highest power capability of the fastest connection power possible, you are making your average initial connection strength about 15 or more db weaker.(Again a problem)


Even if you were compensate for the weaker receive sensitivity encountered at high connection rates (by setting the TX power at each rate) , you now encounter new problems where the initial connection basic rate would need to be about 31 db weaker than the fastest connection TX power. Thus, all rates slow and fast have the same db level at the AP - however all clients are now about 31 db weaker at initial connection rates - which again will result in wireless network problems.(Again a problem)


Here is another example of why a "do-not-track-after-initial-connection" is needed:
假设你有两个APs占地。Mikrotik clients (nv2) typically will always connect to the first (lowest) frequency in the scan-list. So in this example, with your two APs, NV2 clients will connect to the lowest frequency AP and not necessary the best AP. In a very busy nearly congested area with a dozen APs, the lowest frequency AP might get 80 connections, and stronger APs at higher frequencies may only get 1 or 2 connections. Thus, you can not equally load-share your APs with a near equal number of clients each per AP.
Using the current wireless access-list required-signal-strength results in many clients (possibly hundreds of clients) continuously connecting to the lowest frequency AP, rate-shifting up and then getting disconnected - over and over and over and over and over again forever - because wireless access-list required-signal-strength is tracking and auto disconnecting clients.
Also - even if you set the maximum number of clients per AP to something like 30, now you encounter another problem where for some clients the best AP is no longer accepting new connections (because # of connections = max connections).

Another possible side-effect benefit to having a "do-not-track-after-initial-connection" might be lower CPU resources used(because it is no longer tracking 100 percent of all the connections)．因此可能resulting faster/better CPU processing of all wireless connections. Also, a strong benefit to having a "do-not-track-after-initial-connection" would be a well balanced client count among multiple APs into a specific coverage area.








North Idaho Tom Jones

One option would be to add additional setting "signal-out-of-range-time" where you could adjust the time how often to check the signal. By default we could leave 10seconds. Also we could add an option 'infinite', where it would check the signal only on the initial connection.
Would such solution be ok?

One option would be to add additional setting "signal-out-of-range-time" where you could adjust the time how often to check the signal. By default we could leave 10seconds. Also we could add an option 'infinite', where it would check the signal only on the initial connection.
Would such solution be ok?

First of all - thank you for getting back to me on this subject.

I big time prefer the option to "check the signal only on the initial connection".
Using a "Also we could add an option 'infinite'" should accomplish the same thing

Any checks after the initial connection could result in a connect-disconnect-connect-disconnect loop for some clients that are just strong enough for a basic rate connection , but then would disconnect as rates climb and db gets weaker.

Thank you - I could really use this:

North Idaho Tom Jones

One option would be to add additional setting "signal-out-of-range-time" where you could adjust the time how often to check the signal. By default we could leave 10seconds. Also we could add an option 'infinite', where it would check the signal only on the initial connection.
Would such solution be ok?

Thinking about it, Along with what I want"add an option 'infinite'"．, I might be interesting to be able to schedule (or cron) , a time-check-window which can be set with this range

infinite & seconds & minutes & hours & days

The reason for the days (or weeks/months), is that possibly a new function could be achieved which can flick off all long-connections , possibly to spread or rotate the connections. Not quite sure yet , but if you are working on the scheduler , might as well open it up some .

North Idaho Tom Jones

Good news

I have been testing 6.41rc30 and so far it looks good and appears to solve the issue/request wanted/needed.
A huge thanks to Mikrotik for this

At this time, there is a new option/feature in the CLI (not in the Web interface or Winbox).
The new option/feature is "allow-signal-out-of-range=always"

I performed my testing on a single AP covering a small city which also has 16 other redundant APs also covering the same area.
On my test AP, I would often have 50 to 80+ client connections. This same AP would climb to 100+ client connections when all other APs were rebooted.
After the procedure noted below, I was able to drive down the number of client connections to 34 or less if I wanted. The rest of the other clients with weaker connections were then forced to connect to other redundant APs facing the same direction.

Thus - I can now achieve AP load balancing with a huge base of Mikrotik clients into a pool of APs facing the same direction. This better distributes the clients more evenly among multiple APs and now provides better average client throughput because I no longer have one or a few APs saturated with client connections.

What I did:
On my test AP, I first cleared all interface - wireless - access-lists
Then using the CLI I did this:
/interface wireless access-list
then using the CLI I did this:
add allow-signal-out-of-range=always authentication=no comment="Required signal strength to connect" forwarding=no interface=wlan1 signal-range=-120..-57

Note: The important part of the above line is the "-57" at the end. This is the value the AP uses to determine if the client may connect.

This -57 number is the required signal strength to connect. You may want to play with the -57 number in your testing.
This -57 number has nothing to do with the required signal strength to stay connected after rate-shifts.

The new "allow-signal-out-of-range=always" part means never check the signal strength again after the initial connection.

In my testing of this RC , I give it a huge thumbs up

Thank you Mikrotik
I look forward to seeing this in a current release

North Idaho Tom Jones

By the way, can't one use another rule to drop connection with weak signal (like -120..-85)?
Will it work like 'connect on -55, work on -70, disconnect on -85'?

By the way, can't one use another rule to drop connection with weak signal (like -120..-85)?

Code:Select all

/interface wireless access-list add allow-signal-out-of-range=10s authentication=no interface=wlan1 signal-range=-120..-85 place-before=0

Will it work like 'connect on -55, work on -70, disconnect on -85'?

I think you can still use all kinds of access-list rules with this:
Possible Example:
0 bla bla always-permit mac address aa:bb:cc:dd:ee:ff any all-of-the-above
1 bla bla always-permit mac address 22:22:22:12:34:56 any all-of-the-above
3 bla bla never-permit mac address 22:22:22bc:fe
4 bla bla never-permit mac address 22:22:22:fe:fe:fe
5 addallow-signal-out-of-range=alwaysauthentication=no comment="Required signal strength to connect" forwarding=no interface=wlan1 signal-range=-120..-57
6 comment "disconnect the really weak"allow-signal-out-of-range=10sauthentication=no interface=wlan1 signal-range=-120..-85 place-before=0[/code]

However - the more access-list lines also equals more processing needed by the CPU to keep checking these access-list rules.

I would think a single line access-list entry (#5 above) should be all that would be needed when all clients are at fixed non-moving locationsl
I would think a multi line (like above) might be more useful if you have any mobile clients


North Idaho Tom Jones

Re the connect strength and disconnect strength

The connect strength should be easy to guess/estimate.
The closer the -number gets to 0 (zero) the stronger the initial connect signal must be.

The second rule for auto-disconnect should be around 30-ish db weaker
- Need to account rate-shifting tx & rx signal loss
- Also pad the auto-disconnect rate 3 or 6 db to allow for all possible tx & rx rate-shift db loss that be slightly out of documented specifications for tx power & rx sensivity

North Idaho Tom Jones

Re: Will it work like 'connect on -55, work on -70, disconnect on -85'?

I suppose you could make an array of APs covering the same area to do something like this:

AP #1 - Only accept 0 to -45 db
美联社# 2——只接受45 to -55 db
AP #3 - Only accept -55 to -65 db
AP #4 - Only accept -65 to -75 db
AP #5 - Only accept -75 to -85 db

In the above, you can split you client connection counts to APs by signal strength.
As to why somebody might want to do something like this - - - well here is a possible reason:
AP #1 above might have the closest clients, set the NV2 cell small
AP #2 above through AP #5 above have more distant clients and larger NV2 cell sizes
AP #5 above uses a really high-gain antenna with a large NV2 cell size specifically to handle only distant clients.
AP #5 above might also be locked in a lower rates to prevent rate-shifting and be configured for high-retry times. A last resort configuration to keep a client connected when the signal is almost to weak to work with.

Another possible use for the above
AP #1 (mimo 2x2 AC only)
AP #2 (mimo 2x2 N only)
AP #3 (mimo 1x1 A only)
AP #4 (mimo 1x1 A only all rates locked at 6-meg high retry settings)
AP #5 (anybody connected to this AP needs to have on-site tech to fix out-of-bounds weak-signal --- anybody connected here is almost broken , go fix them)




In my case - Covering several smaller cities and country-sides with sector and grid and spot-beam antennas using this new feature now gives me some options for how I want to distribute my client count load using db levels.

North Idaho Tom Jones

Another possible use for this new feature could possibly be used to help solve a problem/question asked in the Mikrotik Wireless forum about how to build an AP network for 2,000+ wireless clients (at a convention center ).

With this new feature - using same SSID on all APs - All APs bridge wlan(s) to a common natted network could be made to work better with something like this:
——几十个APs放置在一个蜂巢细胞pattern where these APs allow strong signal connections, low retry settings, mimo 2x2 or 3x3 G/N/AC Ce or Cee connections (20/40 MHz wide channels) , and the disconnect level is about 20 db weaker. Thus when roaming clients are near a cell, they connect. As clients roam towards other cells, they are auto-disconnected sooner which forces a roam to the next closes cell.
- In the 4 corners of the room, use 90 degree sector antennas with B/G/A APs set to only 20 MHz wide channels and high retry-count settings.

Something like this would allow your fast mini-cell APs to accept strong local clients and disconnect them quicker when they roam.

The intent of this would be to better distribute 2,000+ roaming clients by signal-strength db level to the best AP and improve the total system-wide wireless network throughput.

Currently -withoutthis new feature, you can not setindependent connect strengthsandauto-disconnect strengths, which can make you end-up with an un-balanced client load to all of your APs.

This may deserve some thought , but a well thought-out design might radically improve throughput for a large roaming client base.

North Idaho Tom Jones

Another possible use with this new feature which could be used by a WISP to fixed-location clients might be something like this:

- 2 (or more) APs (nv2) facing the same directions (identical AP hardware)
- many remote clients at distances from 0 to 30 km.
-- stronger signals are probable closer remote clients

1st AP requires a stronger connect signal strength, and has a nv2 cell size of 10, and fewer retries setting
2ns AP requires a weaker signal strength, and has a nv2 cell size of 20 to 30, and high retries setting

With this, the 1st AP is balanced/tuned for your closer stronger clients
With this, the 2nd AP is balanced/tuned for your further weaker clients

Without this new feature, both APs had to be configured the same for everybody.
Now with this new feature, it is possible to better tune the AP network for greater throughput and also better handle weaker more distant clients.

North Idaho Tom Jones

In testing the RC access-list new feature "allow-signal-out-of-range" ,

I upgraded from 6.41rc30 to 6.41rc31

The CLI commands for this RC feature appear to be the same
-and-
The new RC feature also appears to be still functioning

FYI:
If you want to test this new RC Access-List feature then do this:
- On a test AP, upgrade/install 6.41rc31
- Suggested step , remove all access-lists
- Using the CLI , go to /interface wireless access-list
- Paste in the following line:
add allow-signal-out-of-range=always authentication=no comment="Required signal strength to connect" forwarding=no interface=wlan1signal-range=-120..-55

Note: The line above assumes you are using the wireless interface wlan1
Note: The -55 value is the signal strength the AP requires for a client to connect. Working values you might want to play with are probably -50 through -65.

This new RC feature as I have an example above does not auto-disconnect any clinets - even if their signal strength gets weaker or stronger.
This new RC feature as I have an example above does require (as seen by the AP) client signal strengths to be a minimum of what you specify (in my example above I use -55).

North Idaho Tom Jones

Another example of how this new access-list (currently RC) could be used:

Let's say you have a single public hot-spot for public access (possibly in your home or business).
One problem is that often , people will be outside parked in their vehicles or in the general outside area who can use your hot-spot.
As a business, you want these clients to come into your business and possibly purchase something.
As a home AP hot-spot, you may not want the entire neighborhood connecting to your public hot-spot.

It is now possible to set the required signal strength to be just strong enough where the client must be a few feet away from your public hot-spot for the client to be able to connect. If the client is not close enough to meet the required signal strength to connect, then the client must enter your home or business (and as a business, the client might now purchase something). No more outdoor near-by hot-spot clients connecting to your AP unless they come in.

After a client connects to you public hot-spot, the client may now leave the general high-strength area of the AP and now go outside or possibly hundreds of feet away and stay connected. When the client gets far enough away , eventually the client connection to your public hot-spot will drop. Forcing the client to come back in and re-connect again or force the client to search for other public hot-spots.

在我的ISP /缕/互联网业务,我们有一个第一版er lab that is open to the public and we want them to come in. One problem we experience is clients will often never come in and remain in their vehicles using our public hot-spot for free Internet access. Now the client has only two options, purchase a home Internet account from us or come into our building every time they want Internet access.

This new RC feature as described here could also be useful schools - forcing students to come in to connect then they may leave the general area after they have connected.

North Idaho Tom Jones

Whoa ...

You may want to verify this problem/issue I am encountering with my NV2 clients failing to connect to many of my NV2 APs.

First - There have been some posts - including some be me - about NV2 clients not connecting to some/many/multiple NV2 APs.

It appears from what I am encountering - and from what I have read in other Mikrotik forum posts , that a NV2 client performs the following steps to select to a NV2 AP to connect to.
#1 - site survey
#2 - then attempt to connect to a NV2 AP which is the strongest NV2 AP seen or the second strongest NV2 AP seen. If no connection is established, the NV2 client will only cycle through and attempt to connect to the two NV2 APs and never attempt a connection on any other NV2 APs.

Thus, in my network at one location, I have 9 NV2 APs that can be seen by the client NV2 Mikrotik. The client will only try to auto connect to only 2 of the 9 NV2 APs.

This presents a problem. If both of the strongest seen NV2 APs deny the client from connecting, then the client NV2 Mikrotik will never connect to any of the other 7 available NV2 APs.

So , in my testing of the new ROS "allow-signal-out-of-range=always" (RC) feature , it does not work properly (because I have more than two NV2 APs seen by my NV2 clients).

I was aware that NV2 clients do not and can not roam between different NV2 APs while connected. But it now appears that NV2 clients can not properly search/roam when not-connected when there are more than two NV2 APs.

Also related to this, I suspect the problem may also sometimes be happening to the client NV2 Mikrotik when there is more than one NV2 AP - not sure yet.

Prior to testing this new (RC) "allow-signal-out-of-range=always" feature, I have been encountering this client NV2 connect problem with hundreds NV2 clients. Where NV2 clients would never connect to other NV2 APs when the strongest NV2 AP had a access-list do-not-allow-connection set.

Now with this new (RC) "allow-signal-out-of-range=always" feature on key NV2 APs, the NV2 client problem I am seeing has grown much larger and has been causing NV2 clients to never be able to connect. Today, I found out that since I started using the new (RC) "allow-signal-out-of-range=always" on some NV2 APs a few days ago, that some/many of my NV2 clients/customers have been unable to connect to anything.

In further testing this condition, I have performed some site-surveys on several of the problem effected NV2 clients. If I modify the client NV2 scan list to be a specific frequency of any of my 9 NV2 APs, the NV2 client will connect and run with no problems. However - when a NV2 client uses a scan-list for all of my 9 NV2 APs - where the two strongest NV2 APs seen by the NV2 client have an access-list deny configuration for the client NV2 connection, the NV2 client will never connect --- although there are 7 additional/available NV2 APs.

I suspect this is only a NV2 issue. I further suspect non-NV2 protocols probably work correctly.

I welcome any posts from others who have encountered this NV2 client connect scan-list issue.

Soooo, at this time, how do you auto load balance several hundred NV2 clients to many NV2 APs without tweaking the NV2 client scan-list ???

North Idaho Tom Jones

add allow-signal-out-of-range=always authentication=no comment="Required signal strength to connect" forwarding=no interface=wlan1 signal-range=-120..-55

if my original rule accepts -80..120 and rejects -120..-81... do i need these rules still? or do i remove the reject rule altogether?