Community discussions

 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Mon May 06, 2019 11:27 am

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!!!
You do not have the required permissions to view the files attached to this post.
 
User avatar
Exiver
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 10, 2015 6:45 pm
Location: Germany

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

Mon May 06, 2019 3:20 pm

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..
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Mon May 06, 2019 4:15 pm

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..
I have now at least 1 CAP AC2 which does not work on 5GHz. In CLI it is shown as "running-ap".
 
User avatar
Exiver
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 10, 2015 6:45 pm
Location: Germany

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

Mon May 06, 2019 4:37 pm

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
 
whatever
Frequent Visitor
Frequent Visitor
Posts: 91
Joined: Thu Jun 21, 2018 9:29 pm

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

Mon May 06, 2019 7:00 pm

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.
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Tue May 07, 2019 11:52 am

here are the outputs from CAPsMAN and CAP_IT (which does not working on 5GHz now)
You do not have the required permissions to view the files attached to this post.
 
User avatar
Exiver
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 10, 2015 6:45 pm
Location: Germany

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

Tue May 07, 2019 8:56 pm

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
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Wed May 08, 2019 9:58 am

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.
You do not have the required permissions to view the files attached to this post.
 
User avatar
DanielJB
Frequent Visitor
Frequent Visitor
Posts: 53
Joined: Mon May 27, 2013 3:05 pm

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

Wed May 08, 2019 10:08 am

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
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Wed May 08, 2019 10:41 am

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
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
 
TimurA
Member Candidate
Member Candidate
Posts: 110
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

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

Thu May 09, 2019 10:04 pm

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
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? :)
Last edited by TimurA on Thu May 09, 2019 11:12 pm, edited 3 times in total.
Image
 
TimurA
Member Candidate
Member Candidate
Posts: 110
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

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

Thu May 09, 2019 10:30 pm

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
You have the same situation, if after a short period does not appear SSID beacon frames, the wlan is disabled.
Image
 
anuser
Member
Member
Posts: 350
Joined: Sat Nov 29, 2014 7:27 pm

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

Fri May 10, 2019 10:02 pm

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?
Last edited by anuser on Sat May 11, 2019 3:37 pm, edited 1 time in total.
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Sat May 11, 2019 1:20 pm

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: Point your client to 5 GHz, you will have better performance...

So, what kind of workarounds to 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?

Good questions!

I've try to find the answers. But haven't find them yet.
 
Marino
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Sun Jun 14, 2015 7:26 pm

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

Sat May 11, 2019 8:04 pm

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?
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.
 
TimurA
Member Candidate
Member Candidate
Posts: 110
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

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

Sat May 11, 2019 10:21 pm

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?
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.
You would analyze what they write! problem on new devices and new chips Qualcomm, QCA9984
Image
 
Simono
newbie
Posts: 49
Joined: Tue Mar 20, 2018 9:41 am

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

Sun May 12, 2019 11:32 am

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

 
Marino
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Sun Jun 14, 2015 7:26 pm

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

Mon May 13, 2019 4:56 pm

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.
After disabling CAPsMAN my 5GHz seems ok.
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Mon May 13, 2019 6:03 pm

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.
After disabling CAPsMAN my 5GHz seems ok.
I've moved out 4 ACs from CAPsMAN. Flight is normal. Yet.
 
anuser
Member
Member
Posts: 350
Joined: Sat Nov 29, 2014 7:27 pm

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

Tue May 14, 2019 8:03 am

I've moved out 4 ACs from CAPsMAN. Flight is normal. Yet.
Have you already reported your findings to MikroTik? (support@mikrotik.com)
 
skb73
just joined
Topic Author
Posts: 9
Joined: Fri Jan 18, 2019 3:29 pm

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

Tue May 14, 2019 10:33 am

I've moved out 4 ACs from CAPsMAN. Flight is normal. Yet.
Have you already reported your findings to MikroTik? (support@mikrotik.com)
I have asked them already about this problem. twice. they are too busy to answer :(
 
User avatar
Caci99
Forum Guru
Forum Guru
Posts: 1046
Joined: Wed Feb 21, 2007 2:26 pm
Location: Tirane
Contact:

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

Wed May 15, 2019 1:42 pm

I've noticed this behavior on a capsman I was configuring with wsap and cAP AC. I noticed some of the interfaces were labeled with "i" (inactive) on the winbox list.
I disabled the DFS on the configuration and that solved the problem. If your APs are close to each other and DFS enabled they will look for free frequency. Because of some regulations on the 5GHz the time is as long as 1 minute before an interface picks up a frequency.
If you wouldn't care much of country regulations, try configuring with no-country and DFS disabled and see if that solves your issue. You may want to lower the interface power in cases where AP are relatively close to each other to cause interference or configure with different channels for those.
-Toni-
Don't crash the ambulance, whatever you do
 
TimurA
Member Candidate
Member Candidate
Posts: 110
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

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

Thu May 16, 2019 10:51 am

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
RB4011 5ghz, the same. suppot file sent to support. my Ticket#2019022722003126, problem since February 27, 2019.

64 bytes from 172.26.0.1: icmp_seq=224 ttl=64 time=7.874 ms
64 bytes from 172.26.0.1: icmp_seq=225 ttl=64 time=3.571 ms
Request timeout for icmp_seq 226
Request timeout for icmp_seq 227
Request timeout for icmp_seq 228
Request timeout for icmp_seq 229
Request timeout for icmp_seq 230
Request timeout for icmp_seq 231
Request timeout for icmp_seq 232
Request timeout for icmp_seq 233
Request timeout for icmp_seq 234
Request timeout for icmp_seq 235
Image
 
kiler129
Member Candidate
Member Candidate
Posts: 215
Joined: Tue Mar 31, 2015 4:32 pm
Contact:

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

Sun Jun 16, 2019 6:28 pm

I think this topic is really about the same issue as viewtopic.php?f=3&t=142298

Who is online

Users browsing this forum: No registered users and 16 guests