Shows online but cannot connect.

[lmq8267]

Starting from commit e42848d ,the issue occurred where the connection failed, but it still showed as being online. There was no problem before this commit record.

[lmq8267]

Now only the one before e42848d submitted the record can be used normally, but the later ones cannot be used normally.

When executing zerotier-cli info, the information is displayed normally. When executing zerotier-cli Peers, the information is displayed normally, but the connection cannot be made. It is normal to use the commit record before e42848d

[stevo11811]

I dont know if this is related but i just spent two days downgrading our clients from 1.14.1 back to 1.12.2 for this exact issue.

All clients showed as DIRECT connected but the traffic was routing out to the ethernet adapter and not over Zerotier, downgrading immediately fixed the issue.

Edit: All clients are Windows 11, not sure if this matters.

[lmq8267]

Mine is a MIPSel platform Linux, not Windows. Version 1.14.0 works fine, but only version 1.14.1 has connection issues.

I tried some of the recent commits. The issue started occurring from commit e42848d, and there were no problems before that. I'm not sure what's wrong with e42848d.

[joseph-henry]

Thanks for reporting this.

All clients showed as DIRECT connected but the traffic was routing out to the ethernet adapter and not over Zerotier, downgrading immediately fixed the issue.

Which architecture are you on?

The issue started occurring from commit https://github.com/zerotier/ZeroTierOne/commit/e42848d37dbb54c5bf8ac8474c0faed6d464bd00

Thanks for reporting this. Looking into it now.

[laduke]

@stevo11811 does your network use tags in the flow rules? Make sure you're not missing the allow ethertype arp line in the rule set.

[stevo11811]

@stevo11811 does your network use tags in the flow rules? Make sure you're not missing the allow ethertype arp line in the rule set.

When running wireshark on the ZT interface i could see packets incoming from my remote host but any outgoing from me would go out the Wifi interface and never hit Zerotier.

If this is a separate issue i will open a separate problem as to not clutter.

# This is a default rule set that allows IPv4 and IPv6 traffic but otherwise
# behaves like a standard Ethernet switch.
#
# Please keep in mind that ZeroTier versions prior to 1.2.0 do NOT support advanced
# network rules.
#
# Since both senders and receivers enforce rules, you will get the following
# behavior in a network with both old and new versions:
#
# (old: 1.1.14 and older, new: 1.2.0 and newer)
#
# old <--> old: No rules are honored.
# old <--> new: Rules work but are only enforced by new side. Tags will NOT work, and
#               capabilities will only work if assigned to the new side.
# new <--> new: Full rules engine support including tags and capabilities.
#
# We recommend upgrading all your devices to 1.2.0 as soon as convenient. Version
# 1.2.0 also includes a significantly improved software update mechanism that is
# turned on by default on Mac and Windows. (Linux and mobile are typically kept up
# to date using package/app management.)
#

#
# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.
#
drop
    not ethertype ipv4
    and not ethertype arp
    and not ethertype ipv6
;

#Client isolation rules, add's Tag's with default set to NO believe it or not.
# Is this member a server?
tag server
id 2
enum 0 No
enum 1 Yes
default Yes
;

# if both members are not servers
break
not tor server 1
;

#
# Uncomment to drop non-ZeroTier issued and managed IP addresses.
#
# This prevents IP spoofing but also blocks manual IP management at the OS level and
# bridging unless special rules to exempt certain hosts or traffic are added before
# this rule.
#
#testing - So far so good
drop
not chr ipauth
;

# Accept anything else. This is required since default is 'drop'.
accept;

[lhongcai]

Me too. My router's operating system is Padavan, with linux kernel version 3. 4. The CPU architecture is mipsel. zerotier v1. 14. 1 Client failed to ping another ZeroTier client. Now I can only continue to use the old version

[lmq8267]

My architecture is also MIPSEL. If both are on version 1.14.1, the status shows a direct connection, but it still cannot connect to the peer. If one is on version 1.14.0 and the other is 1.14.1, it still doesn't work. Only when both are on version 1.14.0 does it work without issues. My iOS is also running version 1.14.0. That's why I tried the recent commit history and found issues starting from commit e42848d.

I specifically tested on an AArch64 architecture Linux (Linux QWRT 5.4.218 #0 SMP PREEMPT Mon Jun 3 18:44:18 2024 aarch64 GNU/Linux), and version 1.14.1 has the same issue; zerotier-cli peers shows DIRECT connections, whereas version 1.14.0 does not have this problem.