Hi, I’m kind of having the same problem.

I have a Raspberry Pi 4 B+ running Raspberry OS for arm64.
Everytime I use zerotier-cli info it either shows OFFLINE or TUNNELED, rarely ONLINE.
I’ve tried configuring iptables, installing another distro/OS, and nothing worked.

I can guarantee my router isn’t the problem, since I have installed zerotier in two laptops running WIndows 10 under the same router and both of them displayed the ONLINE status.

I tried zt-travis’ suggestion too and it didn’t work either.

Here follows what iptables-save generated:

# Generated by xtables-save v1.8.2 on Tue Sep 22 01:36:25 2020
:INPUT ACCEPT [3132:314508]
:OUTPUT ACCEPT [10160:1398718]
-A INPUT -i zt+ -j ACCEPT
-A OUTPUT -m owner --uid-owner 998 -j ACCEPT
-A OUTPUT -o zt+ -j ACCEPT
# Completed on Tue Sep 22 01:36:25 2020

I’ve installed a fresh raspberry pi OS in the last couple weeks and didn’t need to change any firewall config. The default firewall looks like everything is set to ACCEPT.

I’ve tried again, installed a fresh RaspiOS (32x this time) and installed zerotier. It still didn’t show as ONLINE. I configured iptables, gave the corresponding permission to the zerotier-one user. I also tried using ufw as well, but it didn’t work either.

Sorry, I seem to have not finished my thought…

I don’t think it’s your pi or it’s firewall config. The default firewall rules are wide open, they accept everything. Especially if you’re tried many times and even different distributions.

Kind of weird that both people are having the same issue!

What kind of router are you behind?

I’m behind a CDATA Router with a NAT type of FULL CONE.

Side note: I’ve also opened a thread on Reddit and added some extra info from some tests I did:

(I’ve forked the discussion to it’s own thread)

Seems similar:

This user’s only known work around is

for now the workaround i’m currently using is to stop the zerotier’s service for about 10 min and restart it without touching anything else

Does that work for you?
sudo systemctl stop zerotier-one

sudo systemctl start zerotier-one

I left the service down for like 12 minutes, then got it up again, but it didn’t work either.

Also, after some researching from some replies on the reddit’s thread, I found a thread in the Raspberry forum, which was this one.
I’ve installed iperf3 in one of my laptops and in the raspi. Made raspi a server and told my laptop to connect to it via UDP and send some packets. After some tests I found some weird things happening.

Log can be seen here.

Somehow my Raspi stopped receiving datagrams out of nowhere, and most datagrams got lost. I did three tests, the first one went okay the second my raspi stopped receiving (As shown in the prints), then started again mid-test (With an huge amount of data loss), and the third one was very unstable (Sometimes did and sometimes did not accept datagrams).

Cmd on RasPi: iperf3 -s -V
Cmd on Laptop: iperf3 -c 192.x.x.x -u -b 0 -t 60 -V

I’ve also tried following the workaround in the linked thread (which is isolating one of the CPUs) but it had no effect on zerotier’s status or the problem with UDP.

Interesting. Is the pi on WiFi?

edit: reading the thread now…

I’ve reviewed ZeroTier’s manual and stumbled across this info:

We recommend that root servers do not act as network controllers, join networks, or perform any other overlapping functions. They need good reliable network connections but otherwise require very little RAM, storage, or CPU. A root could be a small VM, VPS, or cloud instance, or a small device like a Raspberry Pi. If you provision your roots as VMs, take care that they do not all reside on the same physical hardware. This would defeat the purpose of having two.

It seems like it may be important, but I didn’t quite catch what it really means.

@gabrielrctt That part of the manual is regarding running root servers. That’s not what you’re doing, so it isn’t pertinent to your issue.

Almost sounds like your router is trying to be “smart” and mis-detecting UDP packets as a flood and blocking them. Either way, your iptables rules on your Pi seem fine, so I’d start looking at the next step in the signal change: your router.

This topic was automatically closed after 14 days. New replies are no longer allowed.