cAP-ac Throughput & High Ping Problems

lant · Wed Mar 13, 2019 7:54 pm

We are running into a problem keeping stable wireless connections to the new cAP-ac units we purchased installed at our client's location. I have just completed significant onsite troubleshooting of the problem, but haven't found a solution yet. I am hoping someone on the forums can assist.

The Problem: We are experiencing disconnected RDP connections on handheld Motorola devices running Windows embedded, when connected wirelessly to the new Mikrotik cAP-ac units we installed in a large warehouse. Ping tests from my notebook through the cAP units to the gateway router result in very high jitter. Over several hundred pings, the ping results range from 1ms to over 1200ms. This is while my notebook is stationary and has an excellent signal to the nearest cAP.

Environment: 29 cAP-ac units have been installed in a very large 360,000 square foot warehouse. Each cAP is mounted about 4 foot below the correlated flat roof, spaced out throughout the warehouse. The roof is approximately 30 foot above the floor. In the warehouse there are 63 rows of skid racks. We have mounted cAP units on every other row.

Configuration: All cAP-ac units are centrally programmed using CapsMan, running on an RB3011 router. Only wlan1 is being used on each cAP and all cAP units broadcast the same SSID and use the same frequency. The 5ghz wlan interface is not being used at this time. DHCP client is enabled on the eth1 interface on each cAP. We initially had RouterOS version 6.43 running on both the CapsMan router and the cAP-ac units, but have upgraded to 6.44, without any improvement.

Troubleshooting steps we have tried:
1) Did a wifi analysis and turned off all devices using 2.4ghz channel 1.
2) Confirmed that all cAP units were provisioned to use channel 1, 20mhz channel width. WPA2 encryption enabled.
3) Changed the channel used by the cAPs to 11, but no improvement.
4) Upgraded firmware to 6.44 on the CapsMan router and on about 1/3 of the cAP units closest to where I was running tests - no change.
5) Configured one of the cAP units as a stand alone AP, not configured by CapsMan and turned off the other cAP units in that end of the warehouse. Connections through the stand alone cAP had the same ping jitter problem.
6) Logged into one of the cAP units and ran pings to the local gateway IP. The results were less than 1ms consistently. This would seem to rule out a problem on the ethernet network.
7) Setup one of the cAP units away from the metal roof so that it was located about 15 feet off the floor, and then turned off the other cAP units in that area of the warehouse. We did this to test whether proximity to the flat correlated metal roof had anything to do with the ping jitter. Connected our test notebook over wifi, to the test cAP, 15 foot off the ground and it did not make any difference. Over 100 pings to the local gateway IP, times varied from 1 to 600ms.

Pings from my test notebook connected to the wifi on one of the cAP units to the IP of that cAP seems to show the same high jitter, as when pinging the gateway IP.

I have included a screen capture of the wifi analysis, showing the cAP units assigned to channel 1 and other equipment assigned channel 6 or 11. I have also attached a screen capture of the ping test results, showing extremely high ping jitter, when pinging the local gateway IP, through the cAP units. A third screen capture shows the registration of my test notebook to the cAP nearest me. I am not sure what I need to do to get this wifi network providing stable connections. Any suggestions would be appreciated!

Ping test results from test notbook to WH-R1-MD 3_11_19.JPG

Test Notebook Registration to WH-R1-MD cAP 3_11_19.JPG

Screenshot_2019-03-11-17-09-41.png

mkx · Wed Mar 13, 2019 9:44 pm

WiFi (or any other radio equipment) doesn't work well if there's excessive interference. By configuring all cAPs to use same channel you created lots of interference. You better configure cAPs to use channels 1, 6 and 11 alternately ... and do some planning so that the physical distance between cAPs operating on same channel is at maximum ...

Picture shows large number of different devices ... you should definitely migrate some (as many as possibke) to 5GHz (where you should stick to 20MHz channels to maximize number of interference-free channels).

DSK · Wed Mar 13, 2019 9:49 pm

Looks like some serious interference. Enable reselect interval on CAPsMAN to 15 minutes.
Reduce Tx power.
Install the cAPs in a zigzag format, not rows.
Possibly add more cAPs.
Local forwading.
Control channel- auto
Consider 10 MHz channels

lant · Wed Mar 13, 2019 10:04 pm

Thank you for your suggestions.
We have installed the cAP units in a zigzag format throughout the warehouse, skipping every other row. I have assigned channel 1 through CapsMan, believing that the cAP units would share the airtime on channel 1, as long as there are no other strong interference sources on channel 1 or adjacent channels. Is this incorrect?

To test the theory of interference between the cAP units, I turned off all them off, except one, in about a third of the warehouse. Pings from my notebook through the one cAP unit still running, still produced high jitter. Does this seem to indicate an interference source other than the cAP units that does not show up on a standard 802.11 wifi scan?

DSK · Wed Mar 13, 2019 10:22 pm

Add access list rule on CAPsMAN to drop connections weaker that -65 or -70 depending on usage. This enables roaming of gadgets. Please implement above tweaks then give feedback.

mkx · Wed Mar 13, 2019 10:36 pm

capsMan doesn't make cAPs to coordinate use of air time, they still operate independantly.

lant · Wed Mar 20, 2019 10:19 pm

Thank you MKX and DSK for your suggestions!

After doing a bunch more testing, I found that the high ping times continue to be a problem even when all but one cAP unit is turned off and the single remaining cAP is configured as a stand alone AP, not configured by CapsMan. Further testing found that there are several 2.4ghz APs in the building with hidden SSIDs that we don't have management access to. Because of this, I decided to try 5ghz instead of 2.4ghz for this project. Initially I configured just one cAP to use 5240mhz and ran ping tests though it. These test results were much better than what we were able to get using 2.4ghz, but still varied from single digit ping times to 30ms, to the local gateway IP.

Now I am trying to setup CapsMan to centrally assign the configurations to all 29 cAP-ac units spaced throughout the huge warehouse. I can get CapsMan to assign a single configuration to all cAPs and provsion wlan2 on each, but I would like to alternate between four different 5ghz frequencies, by assigning different configurations to the cAP units based on mac address. Sadly I don't know how to do this properly, because when specify a specific radio mac address in a provisioning rule in CapsMan, it seems to ignore it and provision all of the cAPs, not just the one cAP with the matching mac address. Would someone tell me how to assign a given CapsMan configuration to a specific cAP by mac address, or point me to existing instructions that explain this process?

Thanks in advance for your suggestions!

escandor · Thu Mar 21, 2019 10:07 am

In Provisioning section of CAPsMAN there is a possibility to create items with different "Identity Regexp".
You can draw virtual middle line, all caps located left from middle line will have suffix "L", caps located right will have suffix "R". (Do not forget to change Identity names of Caps)

cap1_L
_______\
________\
_________cap2_R
________/
_______/
cap3_L

in provision profile setup 2 items, one that will provision caps with "*_L" and another one that will provision devices with "*_R" for this profiles you can choose different frequencies.
And do not forget "Access List" rule mentioned before.

mkx · Thu Mar 21, 2019 1:23 pm

I can get CapsMan to assign a single configuration to all cAPs and provsion wlan2 on each, but I would like to alternate between four different 5ghz frequencies, by assigning different configurations to the cAP units based on mac address. Sadly I don't know how to do this properly, because when specify a specific radio mac address in a provisioning rule in CapsMan, it seems to ignore it and provision all of the cAPs, not just the one cAP with the matching mac address. Would someone tell me how to assign a given CapsMan configuration to a specific cAP by mac address, or point me to existing instructions that explain this process?

My experience is that the order of rules in /caps-man provisioning matters ... so the general rule with radio-mac=00:00:00:00:00:00 should come last ...

lant · Thu Mar 21, 2019 3:53 pm

Thank you Escandor and MKX!
Is the identity name used in CapsMans set directly on each cAP under the menu system\identity, or somewhere else?

DSK · Thu Mar 21, 2019 3:56 pm

I believe the reason you want to have different configurations per cAP is so that you can assign frequencies. This may not be the best move.
Create the four channels or more on CAPsMAN, then set channel reselect interval to 15 minutes. This way, cAPs shall select the best channel amongst the preset.

lant · Thu Mar 21, 2019 5:14 pm

Having the cAPs automatically assigned from several frequencies every 15 minutes sounds like an easier approach.
Where to a find the setting in CapsMan for the cAPs do a channel reselect every 15 minutes?

escandor · Thu Mar 21, 2019 6:00 pm

Is the identity name used in CapsMans set directly on each cAP under the menu system\identity, or somewhere else?

Exactly

lant · Tue Apr 02, 2019 4:24 am

Thanks to those that have provided suggestions on this ongoing CapsMan & wireless config issue. I tried using CapsMan to automatically reselect the frequency on each of the 29 cAP-ac units in this 360,000 sq ft warehouse, but I found that too many of the APs were using the same 5ghz frequency. Because of this I have abandoned CapsMan for now and have gone with configuring each cAP-ac unit individually. Currently each AP has the same SSID, and encryption code, but the frequency is assigned in an alternating arrangement to keep the APs that use the same frequency physically separated - ie neighboring APs use different non-overlapping 20mhz assignments. With this configuration, ping times to the local gateway IP are better than before, but still not great. Here are the typical results we are seeing:

Ping statistics for 10.255.1.2:
Packets: Sent = 100, Received = 96, Lost = 4 (4% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 123ms, Average = 26ms

Here is the connection info from the test laptop:

Row35 WiFi Connection Info 4_1_19.png

Here is a graph if what the wifi analyzer sees:

Row35 WiFi Analyzer Graph 4_1_19.png

We are also experiencing wireless devices constantly hopping from AP to AP. To combat this, I have added an access list rule that restricts access to clients with a -65 signal or better, like this:

/interface wireless access-list
add comment="Restrict wifi connections to -65 or stronger" signal-range=-65..120

Sadly the rule above has not fixed the problem. I have also tried to manually decrease the TX power on the radios in the cAP-ac units, but when I do, I get an error that the feature is not supported. Any suggestions as to what I can do to stabilize the ping times and keep the wireless devices from hopping from AP to AP, even when located in one spot?
Reduce the number of cAP-ac units, so we don't have to reuse a given frequency as much?

pcunite · Tue Apr 02, 2019 5:34 am

I have also tried to manually decrease the TX power on the radios in the cAP-ac units, but when I do, I get an error that the feature is not supported.

This is done via the Antenna Gain setting.

escandor · Tue Apr 02, 2019 10:10 am

We are also experiencing wireless devices constantly hopping from AP to AP. To combat this, I have added an access list rule that restricts access to clients with a -65 signal or better, like this:

/interface wireless access-list
add comment="Restrict wifi connections to -65 or stronger" signal-range=-65..120

in this case should be added 2 rules like this. One rule allow access second denies.
/caps-man access-list
add action=accept signal-range=-65..120
add action=reject signal-range=-120..-66

lant · Tue Apr 02, 2019 1:29 pm

Thank you, pcunite and escandor! I will try your suggestions.

dhcpy · Thu Apr 18, 2019 7:25 am

Thank you, pcunite and escandor! I will try your suggestions.

Hello friend!
any news on your scenario?

I'm considering mikrotik for a large warehouse too.
The first thing I'm not so confortable with, is that I think omni antennas/APs are not best suited for this enviroments, but I didn't find sector or panel APs that can cover only the ails.
anyway, did you use some software for planning?

dhcpy · Thu Apr 18, 2019 8:27 am

Thank you, pcunite and escandor! I will try your suggestions.

Hello friend!
any news on your scenario?

I'm considering mikrotik for a large warehouse too.
The first thing I'm not so confortable with, is that I think omni antennas/APs are not best suited for this enviroments, but I didn't find sector or panel APs that can cover only the ails.
anyway, did you use some software for planning?

muetzekoeln · Thu Apr 18, 2019 11:31 am

With this configuration, ping times to the local gateway IP are better than before, but still not great.

Sorry, I just read your thread. Little late I guess....

I think you still have some interference between your APs, but you also may have a severe hidden node problem:

https://en.wikipedia.org/wiki/Hidden_node_problem
viewtopic.php?t=46265

Your APs can be reached well by the stations, thanks to the height and the metal roof. But the stations in the aisles between the racks cannot receive all other stations. If not already done, try "cts-to-self" or "rts-cts" hw-protection-mode.

muetzekoeln · Fri Apr 19, 2019 9:11 pm

If not already done, try "cts-to-self" or "rts-cts" hw-protection-mode.

Well, this was too quick. You can try if enabling RTS/CTS on your ROS APs helps, but most of all, you should try to enable it on your Motorola devices. Also, when enabling RTS/CTS you have to specify a minimum frame size for RTS/CTS kicking in ("Hw. Protection Threshold").

See also:
viewtopic.php?f=7&t=29275&sid=3c1fe0ecc ... 4&start=50

eset · Fri Apr 19, 2019 11:54 pm

I will joing this post also because I see friend here has the same problem that I have. Here is my whole config:

https://gist.github.com/electropolis/6d ... cf3197d670

Just want to mention that although 2.4Ghz are working on different channels , selecting by themself though 5Ghz isn't behaving like that and all caps (four of them) are on the same Channel frequency that you see in the 5Ghz config which is:

# channel: 5180/20-Ceee/ac(14dBm), SSID: MKTBW, local forwarding

The funny thing is that I switched from CapsMAN forward to local forward and it should be faster, quicker, more stable etc.. and it isn't. It's not working properly, user are disconnecting all the time by the access-list which works by the way good but something is making a mess in the radio which seems like those caps are fighting each other for the clients here you have a probe of that: https://youtu.be/r7Z4F3bJMkM on this short clip you see cap number 03 and on the end of the clip 01 came up. Please notice that there are four of them, 02 is also there and 01 is also available and 03 is the small cap hidden in the office which shouldn't be taking so many clients because they are near the 01 and 02 caps as I shown on that picture below:

So basically I'm speechless because I can figure it out.. and I wonder why is this so pain in the ass. We wanted to use mikrotik solutions implement it with capsman but each day my thoughts are rather with a small virtual machine with ubiquti solutions and the same company access points and sell those Access Points .. but please before that I true believe that there is a simple explanation why those caps are behaving like that..

escandor · Tue Apr 23, 2019 11:19 am

So basically I'm speechless because I can figure it out.. and I wonder why is this so pain in the ass.

Have you tried to see what is in the AIR ? There is a lot of tools that can show what is happening in the AIR.
Another question, why in configuration you configure every single AP manually ? CapsMAN can make this "automagically", but for this you need to spend some time for experiments.
Have you checked if other AP accept configuration ?

each day my thoughts are rather with a small virtual machine with ubiquti solutions and the same company access points and sell those Access Points ..

It is never too late. But my assumption that you will have same problems with other solutions. If you can not find reason of you problems.

eset · Tue Apr 23, 2019 3:07 pm

Have you tried to see what is in the AIR ? There is a lot of tools that can show what is happening in the AIR

Yes. No interference. I'm struggling with my own caps which seems to interfere themself each other

Another question, why in configuration you configure every single AP manually ? CapsMAN can make this "automagically", but for this you need to spend some time for experiments.

Who said that I'm not using capsman. I'm using it but not Capsman forwarding but local forwarding which also makes capsman useful. I don't use capsman fw because it makes data unreadable from wifi clients by any sniffer because of DTLS. Although I had that configuration previously and it worked awesome. But because I need to have WiFi analyzed using external sniffer to analyze suspicious traffic I can't use Capsman FW. Also I read that Local Forward is more efficient. But in this scenario Like you all see it isn't.

t is never too late. But my assumption that you will have same problems with other solutions. If you can not find reason of you problems.

I'm afraid your assumptions is wrong. I never had any trouble with any other wifi controllers like Ubiquiti for instance. This is the first time I'm struggling with stuff like that. Second, MikroTik which is driving me nuts proved that it isn't ready solution out of the box where you can just plug , set couple easy things and it works and if, I said if you want to tune something go ahead you can , not like in the other branded vendors access points. It seems unfortunately it doesn't even work like that.. out of the box. I'm very open for someone who can point me where I'm doing something wrong. But I have studied on YouTube official Mikrotik pitfals which are made using MikroTik what to do what not to do.. And over 2 weeks I'm struggling with this. I'm sorry but vendor solutions should be easy in this level , it's not a rocket science to have basic functionality but where it comes to this.. it is because non of this works. I'm hoping someone will look at this confirm that I have good or not good configuration and if everything is ok what needs to be checked also.

escandor · Tue Apr 23, 2019 4:59 pm

Yes. No interference. I'm struggling with my own caps which seems to interfere themself each other

It is a little bit confusing "No interference" and "which seems to interfere themself each other". Don't you think so ?

If you have 2 AP on same frequency and distance between them is small(less than 50m, and no obstacles), you will have interference in 99% of cases.
Even more, rule that was in configuration allows connection to AP with very poor signal.
A lot of people recommend adjusting "signal-range=-80..120" to lower values. In my case "-70...120" works better. Sometimes I think about lowering this values even more.

Who said that I'm not using capsman.

Well, provisioning AP by mac-address using capsman , from my point of view is dong this manually.

If you want to solve your problem try to go in following way
1. AP nearby should have different channel to reduce interference.
2. correctly place AP in office. (I think that this area can be covered by 3 AP and not by 5 less AP less interference. I hope you have less than 50 wireless devices )
3. define set of channels that your AP can use. Auto-selection of channel in Mikrotik is not always the best.
4. lower values for access-list to -65-70.
5. create provision rules not by MAC address. (there is a lot of options by regexp or simply without specification of mac address. If you want separation of AP nearby by frequency you should write rules that identify AP by identity or name).
6. reduce power on AP

eset · Tue Apr 23, 2019 5:15 pm

It is a little bit confusing "No interference" and "which seems to interfere themself each other". Don't you think so ?

By no interference I mean there are no other radio from other offices around.

1. AP nearby should have different channel to reduce interference.

I'v set that from mikrotik because I couldn't get this done from AP itself. They were saying that after connecting them to capmsan, capsman itself is only responsible for setting channels.. so I stuck here and set on capsman

/caps-man channel
add band=5ghz-a/n/ac control-channel-width=20mhz extension-channel=disabled frequency=5300,5340,5500 name=5Ghz reselect-interval=5h save-selected=yes tx-power=14
add band=2ghz-g/n control-channel-width=20mhz extension-channel=disabled frequency=2412,2437,2462 name=2Ghz reselect-interval=1h tx-power=10

and now I've go only one cap available. And making small proof of concept. But problem exists.

2. correctly place AP in office. (I think that this area can be covered by 3 AP and not by 5 less AP less interference. I hope you have less than 50 wireless devices )

They are correct. You see on the picture.

3. define set of channels that your AP can use. Auto-selection of channel in Mikrotik is not always the best.

Look on point 1.

4. lower values for access-list to -65-70.

When I find solution I will do that because right now it's not the problem with caps itself. Like I said only one is working I have the same problem still.

5. create provision rules not by MAC address. (there is a lot of options by regexp or simply without specification of mac address. If you want separation of AP nearby by frequency you should write rules that identify AP by identity or name).

Provision rules are set. There is no need to set it like this you said. After setting the caps (for local fw , set bridge, IP address and cap enabled) they will appear on capsman and in provision tab ready to receive configuration (provision if changed).

So like I said it is managed by capsman and you can check it in /interface wireless

/interface wireless pr
Flags: X - disabled, R - running 
 0  R ;;; managed by CAPsMAN
      ;;; channel: 2412/20/gn(10dBm), SSID: MKTBW, local forwarding
      name="wlan1" mtu=1500 l2mtu=1600 mac-address=64:D1:54:EE:0C:7F arp=enabled interface-type=IPQ4019 
      mode=station ssid="MikroTik" frequency=2412 band=2ghz-b/g channel-width=20mhz secondary-channel="" 
      scan-list=default wireless-protocol=any vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none 
      wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes 
      default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no 

 1  R ;;; managed by CAPsMAN
      ;;; channel: 5500/20/ac(14dBm), SSID: MKTBW, local forwarding
      name="wlan2" mtu=1500 l2mtu=1600 mac-address=64:D1:54:EE:0C:80 arp=enabled interface-type=IPQ4019 
      mode=station ssid="MikroTik" frequency=5180 band=5ghz-a channel-width=20mhz secondary-channel="" 
      scan-list=default wireless-protocol=any vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none 
      wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes 
      default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no 

 2  R ;;; managed by CAPsMAN
      ;;; SSID: MKTBW_Guest, local forwarding
      name="wlan26" mtu=1500 l2mtu=1600 mac-address=66:D1:54:EE:0C:80 arp=enabled interface-type=virtual 
      master-interface=wlan2 

 3  R ;;; managed by CAPsMAN
      ;;; SSID: MKTBW_Guest, local forwarding
      name="wlan28" mtu=1500 l2mtu=1600 mac-address=66:D1:54:EE:0C:7F arp=enabled interface-type=virtual 
      master-interface=wlan1

6. reduce power on AP

You can see that this already done above from interface print.

I see that the problem isn't wifi but STP. Caps in local forward need to have bridge defined. That bridge has the same Priority (0x8000) as capsman. And still even I changed that on Mikrotik to lower CAP , which I'm testing, still sees himself as Root Bridge

/interface bridge> monitor bridge        
                  state: enabled
    current-mac-address: 64:D1:54:EE:0C:7D
            root-bridge: yes
         root-bridge-id: 0x8000.64:D1:54:EE:0C:7D
         root-path-cost: 0
              root-port: none
             port-count: 5
  designated-port-count: 5
           fast-forward: no

And Please before advising me something take a look to configuration or read carefully because when someone has a problem then I require that person who wants help must prepare whole description of config and situation. I made that already. There is a link to Github Gist and I feel like you don't even manage to see it. For example asking me about channels, power etc.

escandor · Tue Apr 23, 2019 7:07 pm

And Please before advising me something take a look to configuration or read carefully because when someone has a problem then I require that person who wants help must prepare whole description of config and situation. I made that already. There is a link to Github Gist and I feel like you don't even manage to see it. For example asking me about channels, power etc.

Your current configuration in git does not define channels for AP.
Your current configuration in git defines extension channel for 5Ghz as "Ceee".

In last example provided , you choose channels that are affected by DFS.

/caps-man channel
add band=5ghz-a/n/ac control-channel-width=20mhz extension-channel=disabled frequency=5300,5340,5500 name=5Ghz reselect-interval=5h save-selected=yes tx-power=14

In my first answer I asked if other AP also accepted configuration supplied. But did not received answer.

And as a result arrogant comments like

I require that person who wants help must prepare whole description of config and situation

I wish you good luck in fighting with wind mills.

eset · Tue Apr 23, 2019 7:35 pm

our current configuration in git does not define channels for AP.

Line 7 & 10 provides what frequency they are using.

Also I've provided forced channel later on.

In my first answer I asked if other AP also accepted configuration supplied. But did not received answer.

Like I said it's not the major problem with radio. It's problem with STP because Caps are using bridge local fw

34 10.10.1.3                                  56  64 42ms 
   35 10.10.1.3                                               timeout                                            
   36 10.10.1.3                                  56  64 0ms  
   37 10.10.1.3                                  56  64 107ms
   38 10.10.1.3                                  56  64 18ms 
   39 10.10.1.3                                  56  64 41ms 
    sent=40 received=36 packet-loss=10% min-rtt=0ms avg-rtt=22ms max-rtt=107ms 
  SEQ HOST                                     SIZE TTL TIME  STATUS                                             
   40 10.10.1.3                                  56  64 72ms 
   41 10.10.1.3                                  56  64 93ms 
   42 10.10.1.3                                  56  64 122ms
   43 10.10.1.3                                  56  64 142ms
   44 10.10.1.3                                  56  64 60ms 
   45 10.10.1.3                                  56  64 92ms 
   46 10.10.1.3                                  56  64 112ms
   47 10.10.1.3                                               timeout                                            
   48 10.10.1.3                                               timeout                                            
   49 10.10.1.3                                               timeout                                            
   50 10.10.1.3                                               timeout                                            
   51 10.10.1.3                                               timeout                                            
   52 10.10.1.3                                               timeout                                            
   53 10.10.1.3                                               timeout                                            
   54 10.10.1.3                                               timeout                                            
   55 10.10.1.3                                               timeout                                            
   56 10.10.1.3                                               timeout                                            
   57 10.10.1.3                                               timeout                                            
   58 10.10.1.3                                               timeout                                            
   59 10.10.1.3                                               timeout                                            
    sent=60 received=43 packet-loss=28% min-rtt=0ms avg-rtt=35ms max-rtt=142ms 
  SEQ HOST                                     SIZE TTL TIME  STATUS                                             
   60 10.10.1.3                                               timeout                                            
   61 10.10.1.3                                               timeout                                            
   62 10.10.1.3                                               timeout                                            
   63 10.10.1.3                                               timeout                                            
   64 10.10.1.3                                               timeout                                            
   65 10.10.1.3                                               timeout                                            
   66 10.10.1.3                                               timeout                                            
   67 10.10.1.3                                               timeout                                            
   68 10.10.1.3                                               timeout                                            
   69 10.10.1.3                                               timeout                                            
   70 10.10.1.3                                               timeout                                            
   71 10.10.1.3                                               timeout                                            
   72 10.10.1.3                                               timeout                                            
   73 10.10.1.3                                               timeout                                            
   74 10.10.1.3                                               timeout                                            
    sent=75 received=43 packet-loss=42% min-rtt=0ms avg-rtt=35ms max-rtt=142ms 

[konrad@BB-RT-01] > ping 10.10.1.3
  SEQ HOST                                     SIZE TTL TIME  STATUS                                             
    0 10.10.1.3                                  56  32 22ms 
    1 10.10.1.3                                  56  32 53ms 
    2 10.10.1.3                                  56  32 71ms 
    3 10.10.1.3                                  56  32 102ms
    4 10.10.1.3                                  56  32 21ms 
    5 10.10.1.3                                  56  32 42ms 
    sent=6 received=6 packet-loss=0% min-rtt=21ms avg-rtt=51ms max-rtt=102ms 

[konrad@BB-RT-01] > ping 10.10.1.91
  SEQ HOST                                     SIZE TTL TIME  STATUS                                             
    0 10.10.1.91                                 56  64 1ms  
    1 10.10.1.91                                 56  64 2ms  
    2 10.10.1.91                                 56  64 1ms  
    3 10.10.1.91                                 56  64 1ms  
    4 10.10.1.91                                 56  64 1ms  
    sent=5 received=5 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=2ms

And as a result arrogant comments like

The Truth is always a pain in the ass. Rather to be so sensitive take it to consideration because I'm tired to receive the same advises .. check radio, check powe TX.. That's already provided and if you could look closely to the config you would notice that antena gain is modified channels are different and Capsman is working.

I wish you good luck in fighting with wind mills.

Thank you.

eset · Tue Apr 23, 2019 8:52 pm

The temporary solution is disabling STP on both Mikrotik (capsman) and CAPs on bridge interfaces. Those interfaces have automatically enabled RSTP when bridge interfaces were added for Local Forward configuration. Strange is that when I wanted to force using STP and setting correct priority for capsman (lowest) caps bridge interfaces were still acting as Root Bridge :/

escandor · Wed Apr 24, 2019 12:50 pm

The Truth is always a pain in the ass.

Reading documentation is a "must".
From original configuration was not specified that you are using STP. Even if Mikrotik is recommending using RSTP.
Following step by step capsman configuration guide (specially prepared by Mikrotik ) can save a lot of time.
here is a link.
https://wiki.mikrotik.com/wiki/Manual:S ... sMAN_setup

especially pay attention to step 3, it will help you to solve the problem.

eset · Wed Apr 24, 2019 3:14 pm

You know that is useless chat about basic stuff I should do which I've already done. If it were so simple I wouldn't be writing. I'm writing because I reached all my ideas and knowledge for that.

Reading documentation is a "must".

True

And that's why I used
https://wiki.mikrotik.com/wiki/Manual:C ... rding_Mode

And you provided me with a simple capsman with capsman forward which is totally different configuration which I presented.

From original configuration was not specified that you are using STP. Even if Mikrotik is recommending using RSTP.

Seriously? First of all I'm not providing default MikroTik configuration because I used export compact command to provide the configuration. This gives adds of configuration without default settings. So adding bridge every time on MikroTik is set by default with Spanning Tree Protocol regarding to your "was not specified that you are using STP" and method by default is RSTP so you were saying "Even if Mikrotik is recommending using RSTP. " and I don't know if I know what did you meant but STP is a functionality and RSTP is one of the STP method used in that functionality. I think you misunderstood those two concepts. In your link there is no solutions because that's not for Local Forwarding. Maybe if you wanna help read about Local Forward mode.

My Update was clear here, the RSTP is a problem. Configuration is made using switch-chip VLANs and Capsman in Local Forwardig mode. My router is RB3011 so it has built-in switch chip and supports vlan table so I'm capable to do vlan switching. But this , using vlans has some issues with RSTP. So basically STP must be disable from what I understand in my case in this scenario (local fw) if I'm wrong someone else can correct me I appreciate that

ZschimmerIT · Sun Sep 15, 2019 3:51 pm

Hi @all,

I do have problems with the new CAP_ac AP's as well.
With configured multi- SSID's after some time the virtual SSIDs disapear. (FW 6.44)
Support mail from MT explained that the FW is still buggy and they send me a beta release.
With this the SSID's were more stable but still sometimes disapearing.

Also the signal quality and speed is a pain with this antennas.
I think It's the hardware and bad antenna design so these units are trash!
Same setup with WAP_ac devices is running like a charm...

So please MT improve these CAP_ac's or remove them from your product-list...

cheers

ivicask · Mon Sep 16, 2019 8:25 am

I allways have similar problems with mikrotik and 2.4 ghz , do you have b/g/n enabled? Try set it to -g/n only, or N only if all devices support it.

anuser · Mon Sep 16, 2019 9:01 am

Support mail from MT explained that the FW is still buggy and they send me a beta release.

What beta? Does the problem exist with v6.45.6?

cAP-ac Throughput & High Ping Problems

cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems

Re: cAP-ac Throughput & High Ping Problems