Failed to join CAPsMAN (CAP lost connection, send timeout)

yegle · Mon May 01, 2017 9:17 am

Hi list,

First post here, so forgive me if anything is missing or unclear to you.

Some context: I brought 3 WAP ac (G-5HacT2HnD) to be used as CAP, and a 951G-2HnD as manager. Two of the 3 WAP ac successfully joined the manager and everything is fine, but one shows a weird symptom that just refuse to join the manager. I've tried to reset this particular device multiple times but was still unable to get it working. I even wonder if this is a defect product and will need to RMA it.

I copied the debug log, along with the relevant configs below. Both the manager and the CAPs are in 6.39 (the latest version). Any help would be appreciated, thank you!

apr/30 23:04:19 caps,debug CAP Sulking->Discover
apr/30 23:04:19 caps,debug CAP discovery target list:
apr/30 23:04:22 caps,debug CAP discovery over, results:
apr/30 23:04:22 caps,debug   951G2HnD (::ffff:XXX.XXX.XXX.XXX:5246)
apr/30 23:04:22 caps,debug   951G2HnD (XX:XX:XX:XX:XX:XX/3/0)
apr/30 23:04:22 caps,debug CAP Discover->Select
apr/30 23:04:22 caps,info CAP selected CAPsMAN 951G2HnD (XX:XX:XX:XX:XX:XX/3/0)
apr/30 23:04:22 caps,debug CAP Select->Connect
apr/30 23:04:22 caps,info CAP connected to 951G2HnD (XX:XX:XX:XX:XX:XX/3/0), CommonName 'CAPsMAN-XXXXXXXXXXXX'
apr/30 23:04:22 caps,debug CAP Connect->Join
apr/30 23:04:31 caps,debug CAP lost connection, send timeout
apr/30 23:04:31 caps,info CAP failed to join 951G2HnD (XX:XX:XX:XX:XX:XX/3/0)
apr/30 23:04:31 caps,debug CAP Join->Select
apr/30 23:04:31 caps,info CAP selected CAPsMAN 951G2HnD (::ffff:XXX.XXX.XXX.XXX:5246)
apr/30 23:04:31 caps,debug CAP Select->Connect
apr/30 23:04:31 caps,info CAP connected to 951G2HnD (::ffff:XXX.XXX.XXX.XXX:5246), CommonName 'CAPsMAN-XXXXXXXXXXXX'
apr/30 23:04:31 caps,debug CAP Connect->Join
apr/30 23:04:40 caps,debug CAP lost connection, send timeout
apr/30 23:04:40 caps,info CAP failed to join 951G2HnD (::ffff:XXX.XXX.XXX.XXX:5246)
apr/30 23:04:40 caps,debug CAP Join->Select
apr/30 23:04:40 caps,debug CAP did not find suitable CAPsMAN
apr/30 23:04:40 caps,debug CAP Select->Sulking

CAP config:

/interface wireless cap export
set certificate=request discovery-interfaces=ether1 enabled=yes interfaces=\
    wlan1,wlan2 lock-to-caps-man=yes

CAPsMAN config:

/caps-man channel
add band=5ghz-a/n/ac name=5ghz-channel
add band=2ghz-b/g/n name=2ghz-channel
/caps-man datapath
add bridge=bridge-local local-forwarding=yes name=default
/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm name=default passphrase=XXXXXXXXXXXX
/caps-man configuration
add channel=5ghz-channel country="united states" datapath=default mode=ap name=\
    5ghz-default security=default ssid=XXXXXXXXXXXX
add channel=2ghz-channel country="united states" datapath=default mode=ap name=\
    2ghz-default security=default ssid=XXXXXXXXXXXX
/caps-man manager
set ca-certificate=auto certificate=auto enabled=yes upgrade-policy=\
    suggest-same-version
/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=ac master-configuration=\
    5ghz-default name-format=identity
add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=\
    2ghz-default name-format=identity

yegle · Sat May 06, 2017 10:18 am

Bump.

Still no clue and I have to disconnect the problematic one since it generates a huge heat compare to the other two devices (probably due to the excessive retry in joining CAPS-MAN).

Olytitor · Tue May 16, 2017 5:06 am

You changed the settings capsman > interface??? Check!

anuser · Thu Dec 14, 2017 2:25 pm

Did you find a solution?

flayerfilliper58 · Mon Aug 27, 2018 3:23 pm

Not sure if that's your case but I had similar log entries when the cause was simply bad signal, which is very likely if you're using 2.4GHz. Wireless clients don't like to switch to a new AP if the one they're already connected to is at all visible, even if the signal strength is really bad.

In my case something like this helped:

/caps-man access-list
add action=accept interface=any signal-range=-80..120
add action=reject interface=any signal-range=-120..-81
Basically, kick off anything with signal below -80, so the client would connect to a closer AP with better signal. You might need to adjust the threshold based on your situation.

sujirou · Wed Nov 07, 2018 10:24 am

for some reasons, RouterOS craps out on this one especially when there are automation scripts. you can see on "system > scripts > Jobs" that the window if flooded with entries. this gets fixed by rebooting the router.

yegle · Wed Nov 07, 2018 7:12 pm

In case someone find this post:

I left that particular wAP ac out and just used the other two. Months later when I do need to use an additional AP, I connected it and updated the ROS version. Lo and behold it's working just fine now.

Still don't know what went wrong.

SeparateReality · Sun Jan 24, 2021 9:07 pm

This is quite old but I had the same situation and finally found out what was wrong (in my case).

My Cap was also set to certificate=request and after a while I found out that this was causing the issue.
Looking at the detailed Caps Log on the CAPsMan it showed that the CAPsMan could not generate a certificate for the Cap because it already existed. Thats because I used this Cap before in a different setup.

The solution was simply to revoke the existing certificate. The CAPsMan then just issued a new certificate for the Caps and everything went smooth from then on.

tmcnulty1982 · Thu Apr 15, 2021 3:38 pm

The solution was simply to revoke the existing certificate. The CAPsMan then just issued a new certificate for the Caps and everything went smooth from then on.

This was a lifesaver. I could not figure out why this wAP was not getting a certificate, and it turned out that it must have already had one from a previous installation. Finding that certificate (based on the MAC address) and revoking it almost instantly solved the problem. Thanks so much!

mike548141 · Wed Jun 30, 2021 1:12 pm

This is quite old but I had the same situation and finally found out what was wrong (in my case).

My Cap was also set to certificate=request and after a while I found out that this was causing the issue.
Looking at the detailed Caps Log on the CAPsMan it showed that the CAPsMan could not generate a certificate for the Cap because it already existed. Thats because I used this Cap before in a different setup.

The solution was simply to revoke the existing certificate. The CAPsMan then just issued a new certificate for the Caps and everything went smooth from then on.

Thank you for sharing this @SeparateReality. The log of the CAP did not make it clear why it was failing to join the CAPsMAN, and you were correct. As soon as I revoked the certs for the CAP's that couldn't join it was fixed.
Be great if Mikrotik changed the error message in the log on the CAP to say why the CAP couldn't join the CAPsMAN i.e. conflicting certificate. I found afterwards that the log on the CAPsMAN is quite clear about why it failed.

Failed to join CAPsMAN (CAP lost connection, send timeout)

Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)

Re: Failed to join CAPsMAN (CAP lost connection, send timeout)