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
I experienced the same situation today with 6.42.5. I had to restore my cfg finally.
-
-
nescafe2002
Forum Veteran
- Posts: 915
- Joined:
- Location: Netherlands
Re: hAP ac2 CAPsMAN bug
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).
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).
Code: Select all
/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
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.
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
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.
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.
-
-
nescafe2002
Forum Veteran
- Posts: 915
- Joined:
- Location: Netherlands
Re: hAP ac2 CAPsMAN bug
Thanks sindy, it is indeed firewall related. Discovery fixed using this single rule:
These are the log entries during discovery (firewall log=on), hence the 'any' port selection.
Code: Select all
/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.
Code: Select all
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
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
The Wiki (https://wiki.mikrotik.com/wiki/Manual:S ... in_CAPsMAN) suggests using
Code: Select all
/ip firewall filter
add action=accept chain=input dst-address-type=local src-address-type=localRe: hAP ac2 CAPsMAN bug
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
You made my day!!
(hap ac with local capsman interfaces)
(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).