CAPsMAN and CAP AC2 - 5Ghz stops working without any log message

RouterOS Wireless Networking
1

Hello!

SOS!!!

I have CAPsMAN on a CCR 1009 and about 20 APs - CAP AC2

all of them are up to date (long term)

I have a local forwarding and two VLANs.

sometime 5GHz stops working on one or more APs.

I can see this situation in WIFI scanners (no signal on my channels and no my SSID is seeng on my laptop)

It can be fixed very fast - by reconnect it to CAPsMAN.

But it is not a working solution. We cannot use such kind of WIFI in our office. Now at least three of APs stops working on 5GHz.

Please show me the way to solve it!!!
CAP_Razraby_06052019.rsc (1.68 KB)
CAPsMAN_06052019.rsc (10.6 KB)

2

Can you please check the “current-state” listed on interface-list printable with “/caps-man interfaces print detail” ? It should show you whether the access point is in state “running-ap” (thats the status you would want) or in some other status like radar-detection and so on..

3

I have now at least 1 CAP AC2 which does not work on 5GHz. In CLI it is shown as “running-ap”.

4

Without giving us more input all we can do is just guessing what maybe could be wrong…

Please post the output of

→ on capsmanager:
/caps-man interface print detail

→ on cap-client
/int wire print detail

5

I have the same issue, forcing channel reselect is enough to revive the 5GHz interface. I’m using a low channel reselect interval as workaround.

Edit: I’m running only hap ac2 units with local forwarding and one of them acting as capsman, no other hardware involved.

6

here are the outputs from CAPsMAN and CAP_IT (which does not working on 5GHz now)
CAPsMAN_interface_print_detail_07052019.txt (27.9 KB)
CAP_IT_interface_print_detail_07052019.txt (2.45 KB)

7

I think that looks good. Are you able to add the debug-cap rule on that cap which isnt working? We most likely need the part when it stops working so you could maybe log to a file and upload it after you see that its not working anymore?

debug-log rule would be topics=caps,debug

8

I did it. No success. My CAP have lost 5GHz again.

but nothing in log. I attached screenshots. Log file with caps, debug is zero bytes length.
log rules on CAP.JPG
zero length log on CAP with caps debug to disk.JPG

9

I am seeing the same issue with cAP ac2 and hAP ac2, and have an open support case with Mikrotik for ~10 months. We see SSID beacon frames (among other management frames) aren’t transmitted for up to 10 seconds - this evidently occurs due to a compatibility issue with certain 5GHz clients (smartphones).

Mikrotik state they have opened a case with Qualcomm for the radio microcontroller firmware, and they need to know what clients (smartphones) reproduce the issue, if you can narrow it down; I already passed them one (Nexus 5X) and have a second sitting here. If you can capture a trace showing the behaviour with another co-channel radio with ‘/interface wireless sniffer’, or stream to an ethernet-connected host to wireshark and send it to support@mikrotik.com, that would help them/Qualcomm.

Finally, it’s worth pinging the AP from a client, so you can see when this occurs eg [1]; with scripting, you can dump the registration table when ping latency is above say 100ms and narrow it down to one of more clients.

– [1]

$ ping 10.36.0.251 -i 3
PING 10.36.0.251 (10.36.0.251) 56(84) bytes of data.
64 bytes from 10.36.0.251: icmp_seq=1 ttl=64 time=0.817 ms
64 bytes from 10.36.0.251: icmp_seq=2 ttl=64 time=0.864 ms
64 bytes from 10.36.0.251: icmp_seq=3 ttl=64 time=0.816 ms
64 bytes from 10.36.0.251: icmp_seq=4 ttl=64 time=1.30 ms
64 bytes from 10.36.0.251: icmp_seq=5 ttl=64 time=0.858 ms
64 bytes from 10.36.0.251: icmp_seq=6 ttl=64 time=0.848 ms
64 bytes from 10.36.0.251: icmp_seq=7 ttl=64 time=0.891 ms
64 bytes from 10.36.0.251: icmp_seq=8 ttl=64 time=0.871 ms
64 bytes from 10.36.0.251: icmp_seq=9 ttl=64 time=35.5 ms
64 bytes from 10.36.0.251: icmp_seq=10 ttl=64 time=3917 ms
64 bytes from 10.36.0.251: icmp_seq=11 ttl=64 time=916 ms
64 bytes from 10.36.0.251: icmp_seq=12 ttl=64 time=865 ms
64 bytes from 10.36.0.251: icmp_seq=13 ttl=64 time=528 ms
64 bytes from 10.36.0.251: icmp_seq=15 ttl=64 time=1143 ms
64 bytes from 10.36.0.251: icmp_seq=16 ttl=64 time=8744 ms
64 bytes from 10.36.0.251: icmp_seq=17 ttl=64 time=7173 ms
64 bytes from 10.36.0.251: icmp_seq=19 ttl=64 time=1172 ms
64 bytes from 10.36.0.251: icmp_seq=20 ttl=64 time=16849 ms
64 bytes from 10.36.0.251: icmp_seq=21 ttl=64 time=13849 ms
64 bytes from 10.36.0.251: icmp_seq=23 ttl=64 time=7987 ms
64 bytes from 10.36.0.251: icmp_seq=24 ttl=64 time=4987 ms
64 bytes from 10.36.0.251: icmp_seq=25 ttl=64 time=2237 ms
64 bytes from 10.36.0.251: icmp_seq=26 ttl=64 time=133 ms
64 bytes from 10.36.0.251: icmp_seq=27 ttl=64 time=208 ms
64 bytes from 10.36.0.251: icmp_seq=28 ttl=64 time=31.4 ms
64 bytes from 10.36.0.251: icmp_seq=29 ttl=64 time=0.855 ms
64 bytes from 10.36.0.251: icmp_seq=30 ttl=64 time=0.843 ms
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
64 bytes from 10.36.0.251: icmp_seq=31 ttl=64 time=1731 ms
ping: recvmsg: No route to host
64 bytes from 10.36.0.251: icmp_seq=32 ttl=64 time=80.1 ms
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
64 bytes from 10.36.0.251: icmp_seq=33 ttl=64 time=2573 ms
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
64 bytes from 10.36.0.251: icmp_seq=34 ttl=64 time=4768 ms
10

I think that my situation is not the same. My CAP AC2 stops to work on 5GHz with any client. Every client does not see 5GHz SSID from CAP. And it can last for hours… not for seconds

11

I have the exact same problem with RB4011. I have been telling them the same for 3 months already, a problem with iPad Pro 2018, MSI Leopard, Macbook Pro 2016-2017.
now at least it is clear that the SSID beacon is lost. Temporarily solved the problem - I also talked about the solution, at the same frequency I set hAP ac (RB962).

PS
There, Qualcomm has open cases on Synology RT2600ac, there is the same chip (QCA9984) and RB4011. What happens to them at all? :slight_smile:

12

You have the same situation, if after a short period does not appear SSID beacon frames, the wlan is disabled.

13

So it´s friday evening and I´m actually looking for information whether RouterOS has problems with high amount of concurrent connected clients. Reported problems by users: Random disconnects, “no internet”, “yellow exclamation mark”, “cannot ping gateway any longer” … And now I found this thread? Guess what I said to my users from beginning: Point your client to 5 GHz, you will have better performance…

So, what kind of workarounds do exist? Can you please give some details?

  • Except rebooting all cAP ac inbetween class hours, i.e. every 2 hours…?
  • Does the problem exist for
    ---- all frequencies?
    ---- 20, 40, 80 MHz channels? Any difference?
    ---- all known firmware releases: 6.42/6.43/6.44/6.45?
14

Good questions!

I’ve try to find the answers. But haven’t find them yet.

15

My findings on my installation:

  • Using CAPSMAN with a CAP AC and a HAP AC. The (old) HAP AC works flawless
  • Using 80 MHz XXXX (40 MHz XX seems ok)
  • Using automatic freq. selection or a selection of freq. doesn’t seem to matter
  • At least in firmware 6.43 and 6.44

I disabled CAPSMAN a day ago to see if it helps.

16

You would analyze what they write! problem on new devices and new chips Qualcomm, QCA9984

17

I have the same problem with cAP ac and hAP ac2 connected to CCR1009
80MHz XXXX don’t work, I don’t SSID on my devices. 40MHz XX work ok.

Sent from my phone by Tapatalk

18

After disabling CAPsMAN my 5GHz seems ok.

19

I’ve moved out 4 ACs from CAPsMAN. Flight is normal. Yet.

20

I’ve moved out 4 ACs from CAPsMAN. Flight is normal. Yet.

Have you already reported your findings to MikroTik? (support@mikrotik.com)