Page 1 of 1
hAP ac2 CAPsMAN bug
Posted: Sat Mar 31, 2018 6:16 pm
by gudbjarni
Hi when configuring CAPsMAN on the hAP ac2 v6.41.3 (stable)
I can't get the local AP to connect to with CAP. it just hangs with out registering. At the same time I have cAP-ac and they can connect via CAP to the hAP ac2. They are running v6.41.3 (stable)
also.
If move the CAPsMAN config to one of the cAP-ac then hAP ac2 can connect to to it via CAP. As well as all the cAP-ac. So it seems to be a problem with hAP ac2 not beeing able to join itself.
Re: hAP ac2 CAPsMAN bug
Posted: Sun Jul 15, 2018 11:47 am
by Lilarcor
I experienced the same situation today with 6.42.5. I had to restore my cfg finally.
Re: hAP ac2 CAPsMAN bug
Posted: Sun Jul 15, 2018 12:54 pm
by nescafe2002
I noticed this as well and it seems rather version related than model or architecture related.
hAP ac lite tower 6.42.3: local discovery works
hAP ac lite tower 6.40.8: local discovery doesn't work
It can be solved easily by manually entering 127.0.0.1 as "CAPsMAN Address" in CAP (client) configuration on manager and adding single firewall rule (if firewall is used).
/caps-man manager
set enabled=yes
/interface wireless cap
set bridge=bridgeLocal caps-man-addresses=127.0.0.1 enabled=yes interfaces=wlan1,wlan2
/ip firewall filter
add action=accept chain=input src-address=127.0.0.1
Re: hAP ac2 CAPsMAN bug
Posted: Sun Jul 15, 2018 4:08 pm
by diddie17
I suspect it's a different situation, but the only time I've generally had issues connecting a client to the CAPsMAN contoller is when I have reset and reconfigured a hAP, losing the certificate on the hAP.
You have to then revoke the matching certificate on the CAPsMAN controler to allow the client to request a new certificate. I think it has do to with the fact that the MAC address on the wireless radio hasn't changed and so it is looking to use the same certificate on the CAPsMAN side, but the certificate doesn't exist on the hAP.
Re: hAP ac2 CAPsMAN bug
Posted: Sun Jul 15, 2018 9:39 pm
by sindy
Your suspicion is right, it's two different scenarios
The "certificate lost on cAP as a consequence of configuration reset" is one thing, and the "cAP not connecting to CAPsMAN
running on the same box" is another, unrelated, one. And yes, the default firewall rules of the recent versions (6.42.x to date) prevent loopback connections from establishing. An
/ip firewall filter rule
chain=input action=accept in-interface-list=!any on a proper place (like right below the
chain=input action=accept connection-state=established,related one) cures this one. Locally originated packets sent to local address have no source interface, hence
in-interface-list=!any matches these packets and none from outside, as any packet from outside has some
in-interface assigned.
Re: hAP ac2 CAPsMAN bug
Posted: Mon Jul 16, 2018 10:16 pm
by nescafe2002
Thanks sindy, it is indeed firewall related. Discovery fixed using this single rule:
/ip firewall filter
add action=accept chain=input comment=CAPsMAN in-interface-list=!all port=5246,5247 protocol=udp
These are the log entries during discovery (firewall log=on), hence the 'any' port selection.
21:14:47 system,info CAP configuration changed by admin
21:14:47 firewall,info input: in:(unknown) out:(none), proto UDP, 192.168.4.1:5246->192.168.4.1:53881, len 57
21:14:49 caps,info CAP selected CAPsMAN MikroTik (::ffff:192.168.4.1:5246)
21:14:51 caps,info CAP connected to MikroTik (::ffff:192.168.4.1:5246)
21:14:51 caps,info [::ffff:192.168.4.1:53881,Join,[64:D1:54:33:D7:D0]] joined, provides radio(s): 64:D1:54:33:D7:D6,64:D1:54:33:D7:D5
21:14:51 caps,info CAP joined MikroTik (::ffff:192.168.4.1:5246)
21:14:51 firewall,info input: in:(unknown) out:(none), proto UDP, 192.168.4.1:44094->192.168.4.1:5247, len 52
21:14:54 caps,info MikroTik-1: selected channel 2412/20-Ce/gn(20dBm)
21:14:57 caps,info MikroTik-2: selected channel 5180/20-Ceee/ac/P(23dBm)
21:15:01 firewall,info input: in:(unknown) out:(none), proto UDP, 192.168.4.1:44094->192.168.4.1:5247, len 52
21:15:11 firewall,info input: in:(unknown) out:(none), proto UDP, 192.168.4.1:44094->192.168.4.1:5247, len 52
Re: hAP ac2 CAPsMAN bug
Posted: Mon Jul 16, 2018 11:00 pm
by sindy
The packet from :5246 to :53881 is definitely a response, the request hasn't been logged for some reason, so dst-port=5246,5247 would have been enough for connection-state=new. Anyway, there is little point in restricting communication between processes on the 'Tik, that's why my rule contained no other condition than in-interface-list=!all.
Re: hAP ac2 CAPsMAN bug
Posted: Mon Jul 16, 2018 11:50 pm
by whatever
The Wiki (
https://wiki.mikrotik.com/wiki/Manual:S ... in_CAPsMAN) suggests using
/ip firewall filter
add action=accept chain=input dst-address-type=local src-address-type=local
Re: hAP ac2 CAPsMAN bug
Posted: Tue Jul 17, 2018 5:43 pm
by Lilarcor
gudbjarni， how is your ac2’s 5G WiFi speed when your ac2 acts as CAPsMAN ? Mine has around 100Mbps without local forward enabled, very poor. Mine is running 6.42.5
Re: hAP ac2 CAPsMAN bug
Posted: Mon Jul 29, 2019 10:37 am
by sputniki
You made my day!!
(hap ac with local capsman interfaces)
I noticed this as well and it seems rather version related than model or architecture related.
hAP ac lite tower 6.42.3: local discovery works
hAP ac lite tower 6.40.8: local discovery doesn't work
It can be solved easily by manually entering 127.0.0.1 as "CAPsMAN Address" in CAP (client) configuration on manager and adding single firewall rule (if firewall is used).