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.
I experienced the same situation today with 6.42.5. I had to restore my cfg finally.
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
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.
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.
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
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.
The Wiki (https://wiki.mikrotik.com/wiki/Manual:Simple_CAPsMAN_setup#CAP_in_CAPsMAN) suggests using
/ip firewall filter
add action=accept chain=input dst-address-type=local src-address-type=local
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
You made my day!!
(hap ac with local capsman interfaces)