Capsman loosing connection when connected through switch

I was already thinking it was going into this direction …

There is some internal joke between more seasoned users about some basic rules when using MT gear.
It goes like this:

  1. You do not use VLAN1
  2. You DO NOT use VLAN1
  3. You do not use Quickset
  4. You do not use detect internet
    5)…

Background reason:
Mikrotik handles VLAN1 a bit different then how most other suppliers do and when not set up properly, it may break things.
And this might be what you are seeing.
So either make sure VLAN1 is handled as a proper VLAN, or do not use it at all ! (I don’t at home).

This also involves getting rid of all bridges except the one for Docker (and even there, some question if it is needed. You can perfectly do without. But since it’s in MT’s documentation, it’s tolerated …).
Base line: If you need multiple bridges, your VLAN setup is not optimal.

Some switches try to be smart (too smart as it turns out) … and try to detect anomalous traffic. I have a Dlink manged switch and it was messing with NTP traffic (UDP to/from port 123) inside LAN. After disabling that “feature” I have zero problems (since more than a year ago). So check your smart switches to see if they are trying to be too smart.

As to the dumb switch: mostly it’s fine to use dumb switch even in environment with VLANs. Such a switch obviously won’t do any ingress/egress filtering (so it might upset some windows host, where NIC drivers silently strip VLAN headers if they are not configured to be VLAN aware, and IP/IPv6 stack then starts to receive traffic which should not be there, such as IPv6 Router Advertisiements making such NIC to assume IPv6 address from wrong VLAN). But it has to support frames with size of at least 1508 bytes (baby-jumbo frames, standard ethernet is 1500 bytes). If they don’t, then they might drop (or corrupt) frames with full size payload. Shorter frames should survive just fine though. If it’s actually true that your CAPsMAN to CAP communication flows over untagged (default) “VLAN”, then this should not be an issue at all.

Another thing to think about: packet drop. While it’s not really desirable to have packet dropped in a LAN, all TCP-based communication is somehow immune to it (due to TCP’s retransmission mechanisms). UDP-based communication is not immune. And my feeling is that CAPsMAN protocol is particularly fragile (even short communication loss means CAP device to deprovision). Cause for packet loss in LAN environment might be marginal cables[*] and some receivers are slightly less fragile than others (which would explain why some switches don’t cause problems while others do). 80 meters of UTP is quite a long stretch …

[*] my own experience: my UTP cable installer (a knowledgeable electrical technician, but obviously didn’t have much experience with UTP cables) did termination in wall sockets (I did patching in patch panel myself). Static tests were fine (all pins properly connected), but I had a problem with one computer connecting to one of longest cables … and it was less than 40m cable stretch. Then I borrowed a professional UTP cable tester (some Fluke monster of tester) and it came out that none of cables was up to 1Gbps requirements … everything was wrong. When then I inspected the wall sockets, I found out that the guy untwisted all wires in length of around 10 cm (I guess it was easier for him to connect wires to socket). After I twisted those wires again, all Fluke tests came out perfect and I never had any problems with connected devices ever again.

VLAN 3999 for IPTV … are you, by any chance, “victim” of Telekom Slovenije?

I wouldn’t realy call myself a victim :slight_smile: Yes it is from Telekom, but my main internet is on Telemach. I was testing if i can get Multicast over EOIP and use their TV box on my internet connection and it worked without problem. I don’t use this in practice but i just leave it configured and added UDPXY as a docker container on 5009. So now if i open M3U playlist, 5009 pulls Multicast over EOIP, UDPXY changes it to unicast and then it doesn’t causes problems in network anymore (Multicast traffic on all ports and similar things). I made all LAN cables myself, previusly i had 120 meters of CAT6 lan cable and it worked between Mikrotiks but not between Mikrotik and some dumb POE switch. Now i shortened it quite a bit.

The problem is, that there realy isn’t any disconnection, just Caps connection becomes suddenly “interrupted” and after few seconds starts working again.

Now with TpLink switch inbetween for now, no problems at all. This realy is strange. I also made a factoy reset on Zyxell switch. I will check if that helped in anyway later on.

Well i don’t use detect internet and quickset, so i can check two boxes. I’m simply not experienced enough for advanced VLAN configurations and since more people and also my friend over wireless bridge uses this internet connection i cannot realy simply use trial and error system to separate everything into VLANs better because it would take days for me, to make this work.

Separate bridge for traffic that comes over EOIP would probably still be needed.

I will report my findings later on, but for now it seems that the only problem is in switches, that are too smart. I already thinking of buying CRS326 instead of Zyxell but there isnt any real guarantee, that this would help and that it would work without problem.

When frame loss happens, links don’t disconnect … in worst case they may renegotiate to lower speed (e.g. 100Mbps instead of 1Gbps) but even for this frame loss has to be extensive.

But as I wrote, 100m is the “standard” maximum length of ethernet cable (check random internet article on ethernet cat6 cables, e.g. wikipedia article). And, again, cable has to be perfectly made for flawless operation at the extreme length (and both link partners have to be good at it, I’d expect some low-end switches to be less than perfect).

Yesterday i made a factory reset on the Zyxel switch. Then i enabled IGMP snooping on it, connected all CAPs back on Zyxel and for now, it’s all good. I will wait few days, to see if it’s ok.

Also i moved all IOT device back on my main network so i will probably remove IOT bridge and VLAN, because it’s not needed anymore.

What could be those log entries with topic caps,info

disconnected 118.193.59.15, connection interrupted

disconnected 118.193.59.15, ssl: no common ciphers

How could someone try to acess to Capsman?

It appeared at 16:40 and ended at 16:51

Someone trying to find a way in my network?

Quite likely. But I wonder why your firewall allows attempts to connect capsman via WAN?

I tried with all default rules but no change. How to block acess to Capsman from WAN?

You have many firewall rules and I’m not going to verify all of them. But there are quite a few “dangerous” ones. For example:

add action=accept chain=input comment=Winbox dst-port=8291 protocol=tcp

It’s allowing winbox access from everywhere (including internet). I’m guessing that there’s a similarly dangerous one allowing capsman access.

Most likely this one:

add action=accept chain=input comment="CAPSMAN PORTS" port=5246,5247 \
    protocol=udp

It accepts capsman access from EVERYWHERE.
Best to add in-interfacelist=LAN

Then only LAN is allowed.

But I agree, those firewall rules can benefit from a major overhaul … quite some duplicates too.

I deleted those rules because it also works without them. I agree, some cleening would be a good idea, i will try my best.

After i made a factory reset on Zyxel swithch everything was ok for quite some time but now the same problems have returned. Guess i will have to replace this switch and also 5009 in some time, because one of the ports is only working with 100 Mbps without any apparent reason.

I know this, but i need acess to router from WAN. It has a good password. And yes, i know i can use BTH for almost the same acess.




For some unknown reasons i am not getting any email notifications from this forum.

This is still happening. Now i’m not even sure if switch even has any influence on this behavior. For example, i got connection interrupted messages at 20:19:34. Then i went and check what is happening with cameras all around the house, that stream to NVR and this stream even comes in the switch on the same port where CAP is connected. No disruptions and no disconnections at all. I simply have no idea where should i look for error, because error discription in log isn’t the best.

Now i even tried and leave cameras and CAPs on switch and connected NVR on Mikrotik. At 21:29:54 again all CAPs got connection interrupted but cameras show no disconnection at all and stream is fluent. Out of ideas.

What could this be for “caps, info” and how does it get through firewall?

disconnected 199.45.155.69, connection interrupted
disconnected 199.45.155.69, ssl: empty certificate chain received

IP to location shows this IP in USA and in Hong Kong (i have no idea why two locations).

Firewall filter

/ip firewall filter
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" disabled=yes dst-address=127.0.0.1
add action=jump chain=forward comment="jump to kid-control rules" jump-target=kid-control
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-mark=!ppp connection-state=established,related hw-offload=yes
add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp
add action=accept chain=input comment="Accept GRE za delovanje EOIP preko Wireguard. Pogoj za pravilo brez src. adress  je Wireguard v LAN interface listi" \
    protocol=gre
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="Zerotier Forward" in-interface=zerotier1
add action=accept chain=input comment="Zerotier Input" in-interface=zerotier1
add action=accept chain=input comment=Winbox disabled=yes dst-port=8291 protocol=tcp
add action=accept chain=input comment=IGMP disabled=yes protocol=igmp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=input comment=L2TP dst-port=4500,500,1701 protocol=udp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="BTEST Janko" disabled=yes protocol=tcp
add action=accept chain=input comment="BTEST Janko" disabled=yes protocol=udp
add action=drop chain=forward comment="Disable LAN to LAN traffic" disabled=yes dst-address=192.168.0.0/16 src-address=192.168.0.0/16
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
add action=add-src-to-address-list address-list="Port Scanners" address-list-timeout=2w chain=input comment="Port Scanners to list" in-interface-list=WAN \
    protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop Port Scanners" in-interface-list=WAN src-address-list="Port Scanners"
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Tadej L2TP drop" in-interface=Tadej
add action=add-src-to-address-list address-list=connection1 address-list-timeout=5m chain=input comment="First attempt" connection-state=new dst-port=22 \
    protocol=tcp
add action=add-src-to-address-list address-list=connection2 address-list-timeout=15m chain=input comment="Second attempt" connection-state=new dst-port=22 \
    protocol=tcp src-address-list=connection1
add action=add-src-to-address-list address-list=connection3 address-list-timeout=1h chain=input comment="Third attempt" connection-state=new dst-port=22 \
    protocol=tcp src-address-list=connection2,!secured
add action=add-src-to-address-list address-list=bruteforce_blacklist address-list-timeout=1d chain=input comment=Blacklist connection-state=new dst-port=22 \
    protocol=tcp src-address-list=connection3
add action=accept chain=input dst-port=22 protocol=tcp src-address-list=!bruteforce_blacklist

Confirming the same issue. On CAP’s log:

I had the issue once maybe 3 weeks ago. Rebooted 5009 (Capsman and main router), nothing. Rebooted 24 port Zyxel switch, nothing, then i started rebooting all APs on network and it stopped doing this when i rebooted HapAX2 (it happened also before AX2 was put on that place, so it's not device specific). It's like some kind of loop that doesn't stop until you reboot device, that causes problems. AX2 in that place is also switch for 4 more CAPs behind him.

It just throws all CAPs off the network causing connection lost for all Wifi devices every minute or maybe a little bit more.

From then the issue did not reapear yet.

Can you all create tickets, because support told me “We have no other similar reports in the system.“

And they don’t really read forum.

All my CAPs are disconnection when connected to unmanaged switches, but those which directly connected to the CAPSMAN - don’t.

Hello,
I’ve had the same experience and have now disabled Capsman and now running the CAPs separately.

Regards