I don't get an IPv4 address

[pwaller]

zt0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 2800
    inet6 fe80::<withheld>  prefixlen 64  scopeid 0x20<link>
    ether 32:<withheld>  txqueuelen 500  (Ethernet)
    RX packets 1  bytes 164 (164.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 6  bytes 468 (468.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Any advice on how to figure out why?

[adamierymenko]

Is this still happening? There might have been a bit of downtime with the web API. Next version uses a more reliable and secure mechanism by the way.

[adamierymenko]

I'm closing this for now, as nobody else has encountered the problem... and as I said the next version improves this mechanism.

[pwaller]

@adamierymenko, I'm now on 0.4.0, and I'm still getting this.

Note, that when I reported this bug, I had done this simultaneously with two other clients which were succeeding, it is just on one machine that I'm not getting an ip4 address. Any chance we can reopen this bug and try and figure out why?

[adamierymenko]

Sure. Try it with the latest version.

[pwaller]

I don't understand, is not 0.4.0 the latest version?

[adamierymenko]

It is. Was just checking. Can you tell me about the machine? OS version, network configuration, what's it behind, etc.?

[pwaller]

It's gentoo, x86_64, linux 3.8.13. It's behind a NAT router although the machine is set as the DMZ, so packets hitting the external ip address will come in. I use iptables to disallow all inbound connections except a few named ports. Outbound connections are not restricted.

[adamierymenko]

Hmm...

To work, ZT1 must be able to at the very least have two-way UDP conversations on port 8993 with its supernodes. The supernodes are:

198.199.73.93 cthulhu.zerotier.com cthulhu
198.211.127.172 shub-niggurath.zerotier.com shub-niggurath
198.199.97.220 nyarlathotep.zerotier.com nyarlathotep

(The naming scheme is creatures from H.P. Lovecraft's Cthulhu mythos. :)

If your iptables is blocking inbound UDP this might be the problem.

[pwaller]

Please re-open. Still not working.

[pwaller]

Here is the filter fragment of my iptables configuration:

*filter
:INPUT DROP [4619:141646]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1611796:194342144]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p ipv6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 8993 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -p ipv6 -j ACCEPT

[adamierymenko]

I'm not sure if this rule:

-A INPUT -p udp -m udp --dport 8993 -m conntrack --ctstate NEW -j ACCEPT

... is going to work or not. That's saying to accept UDP "new" connections only, and I'm not sure what that would mean on INPUT. I think in UDP a conversation is defined by sending an outbound packet. But your ctstate RELATED,ESTABLISHED rule may catch it.

The definitive test would be to set default policy on INPUT to ACCEPT temporarily and clear the rest of the table, just to see if that works and to rule out iptables.

Also: do you have the 'ip' binary at /sbin/ip on your system? If not it would be unable to call that program to set an IP address.

[adamierymenko]

I figured it out. On Gentoo, the 'ip' command is in /bin, not /sbin. I'm going to have to incorporate a search path into EthernetTap to find its utilities. Will be fixed in next release.

In the short term: sudo ln -s /bin/ip /sbin/ip

[pwaller]

Aha! :)

A little unfortunate that it didn't error out if it failed to be invoked.

[adamierymenko]

Yes, LOG()'ing something will also occur if it can't find its utils.

[pwaller]

Yay, I have an ip4 address. Thanks for your efforts.

Should I be getting an ip6 address?

[travisa]

I am having this same issue. I'm running Ubuntu 13.04 64bit and I'm not getting an IPv4 address. When I check the log in /var/lib/zerotier-one I don't see anything abnormal. I followed the instructions in BUILDING.txt and RUNNING.txt. All that seems to be holding me back is an IPv4 address.

Edit: I tried dhclient zt0 and that didn't seem to work.

Edit 2: I see outbound TX packets however I haven't gotten a single inbound packet.

[adamierymenko]

Hmm... do you know if UDP ports are open? I am showing everything up just fine.

[travisa]

I have port 8993 open. Are there any other ports?

[adamierymenko]

It's 9993 now... I changed the port between 0.5.0 and 0.6.0 cause 8993 conflicted with a commercial product.

[travisa]

Same result still. I have 9993 forwarded.

[adamierymenko]

What distribution are you running?

[travisa]

Ubuntu 13.04 64bit

[adamierymenko]

Try "sudo zerotier-cli listpeers"

[travisa]

200 listpeers
200 listpeers 36f63d6574 198.211.127.172/9993 - 236 0.6.2
200 listpeers 7e19876aba 198.199.97.220/9993 - 171 0.6.2
200 listpeers 8acf059fe3 162.243.77.111/9993 - 121 0.6.2

[adamierymenko]

Try listnetworks ... are you in any networks? If not do "sudo zerotier-cli join 8056c2e21c000001".

[travisa]

Previously I did zerotier-cli join bc8f9a8ee3000001 as referenced in the RUNNING.txt

I tried with zerotier-cli join 8056c2e21c000001 still no IPv4

[adamierymenko]

Hmm... first of all RUNNING.txt must be out of date. Have to look at that. Second of all that ought to work if you are online. Wait a second and see if anything happens. 🎱

[travisa]

My current listpeers

200 listpeers 2cf72b4985 - - - ?
200 listpeers 36f63d6574 198.211.127.172/9993 - 214 0.6.2
200 listpeers 5dbb1e2984 - - - ?
200 listpeers 7e19876aba 198.199.97.220/9993 - 169 0.6.2
200 listpeers 8056c2e21c 162.243.77.111/9994 - 119 0.6.2
200 listpeers 8acf059fe3 162.243.77.111/9993 - 121 0.6.2

My ifconfig zt0

zt0 Link encap:Ethernet HWaddr 32:b4:68:90:ab:f2
inet6 addr: fe80::30b4:68ff:fe90:abf2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2800 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:5262 (5.2 KB)

[adamierymenko]

Wait a few minutes. You should get one now. Thanks for reporting... my test nodes all had cached IPs, and I hadn't noticed that my move of cloud providers borked my database server config on the netconf master and was causing IPs to not be handed out. 🐛

[travisa]

Its fixed now :) Thanks for all the help. I can't wait to test this all out. VERY VERY cool concept

PING earth.zerotier.net (29.5.159.228) 56(84) bytes of data.
64 bytes from 29.5.159.228: icmp_req=1 ttl=64 time=114 ms
64 bytes from 29.5.159.228: icmp_req=2 ttl=64 time=55.2 ms
64 bytes from 29.5.159.228: icmp_req=3 ttl=64 time=49.2 ms
64 bytes from 29.5.159.228: icmp_req=4 ttl=64 time=50.9 ms

[adamierymenko]

Yeah, Earth is a public net but there will be private nets you can create soon. Enjoy!

[sysfu]

I am having the same issue where "ip addr show zt0" does not show an IPv4 address bound to the zt0 interface.

The first network join attempt to bc8f9a8ee3000001 as detailed in the RUNNING.txt file seemed to hang. "sudo zerotier-cli listnetworks" showed this output:

200 listnetworks bc8f9a8ee3000001 ? WAITING_FOR_FIRST_AUTOCONF 0 ? zt0 fe80::307b:f2ff:fe39:3731/64

After reading this thread I also tried to join the 8056c2e21c000001 network with command "sudo zerotier-cli join 8056c2e21c000001" and this was successfull:

200 listnetworks 8056c2e21c000001 earth.zerotier.net OK 60 public zt1 28.57.55.50/7,fe80::307b:f2ff:fe39:3731/64

I can now ping earth.zerotier.net even though output of "ip addr show zt0" command still does not show any IPv4 address bound to the zt0 interface.

FYI on Arch linux "which ip": /usr/bin/ip

[adamierymenko]

That would be because the network ID in RUNNING.txt is wrong! I'll fix that.

On Feb 16, 2014, at 10:10 AM, Seth notifications@github.com wrote:

I am having the same issue where "ip addr show zt0" does not show an IPv4 address bound to the zt0 interface.

The first network join attempt to bc8f9a8ee3000001 as detailed in the RUNNING.txt file seemed to hang. "sudo zerotier-cli listnetworks" showed this output:

200 listnetworks bc8f9a8ee3000001 ? WAITING_FOR_FIRST_AUTOCONF 0 ? zt0 fe80::307b:f2ff:fe39:3731/64

After reading this thread I also tried to join the 8056c2e21c000001 network with command "sudo zerotier-cli join 8056c2e21c000001" and this was successfull:

200 listnetworks 8056c2e21c000001 earth.zerotier.net OK 60 public zt1 28.57.55.50/7,fe80::307b:f2ff:fe39:3731/64

I can now ping earth.zerotier.net even though output of "ip addr show zt0" command still does not show any IPv4 address bound to the zt0 interface.

—
Reply to this email directly or view it on GitHub.

[retorquere]

I'm getting the same. Everything seems to work and I can connect using the ipv6 address, but I'm not getting an IPv4 on Ubuntu 17.10.

[retorquere]

Argh never mind, I had to pick a range from the ZT management interface.

Still, the MacOS peer got an IPv4 address without that.

[jdelrue]

We are facing the same issue with our own created network (c7c8172af1387fb0). We disabled ipv6 and only enabled 4...

[laduke]

@jdelrue It looks like you need to authorize the device on c7c8172af1387fb0 (in the Members section). Hop in https://my.zerotier.com/community if you have any questions!