See issue #2082
We use a call to libnatpmp::ininatpp to make sure the computer
has working network sockets before we go into the main
nat-pmp/upnp logic.
With basic exponenetial delay up to 30 seconds.
I was running into issues with restarting the zerotier service while
"full tunnel" mode is enabled.
When zerotier first boots, it gets network state from the cache
on disk. So it immediately applies all the routes it knew about
before it shutdown.
The network config may have change in this time.
If it has, then your default route is via a route
you are blocked from talking on. So you can't get the current
network config, so your internet does not work.
Other options include
- don't use cached network state on boot
- find a better criteria than "online"
Stumbled upon this while debugging something else.
If we add search domain to our system configuration for
network DNS, then search domains work:
```
ping server1 ~
PING server1.my.domain (10.123.3.1): 56 data bytes
64 bytes from 10.123.3.1
```
It stopped working for ipv4 only networks in Monterey.
See #1696
We add some config like so to System Configuration
```
scutil
show State:/Network/Service/9bee8941b5xxxxxx/IPv4
<dictionary> {
Addresses : <array> {
0 : 10.2.1.36
}
InterfaceName : feth4823
Router : 10.2.1.36
ServerAddress : 127.0.0.1
}
```
The original way we applied default route, by forking
0.0.0.0/0 into 0/1 and 128/1 works, but if mac os has any networking
hiccups -if you change SSIDs or sleep/wake- macos erases the system default route.
And then all networking on the computer is broken.
to summarize the new way:
allowDefault=1
```
sudo route delete default 192.168.82.1
sudo route add default 10.2.0.2
sudo route add -ifscope en1 default 192.168.82.1
```
gives us this routing table
```
Destination Gateway RT_IFA Flags Refs Use Mtu Netif Expire rtt(ms) rttvar(ms)
default 10.2.0.2 10.2.0.18 UGScg 90 1 2800 feth4823
default 192.168.82.1 192.168.82.217 UGScIg
```
allowDefault=0
```
sudo route delete default
sudo route delete -ifscope en1 default
sudo route add default 192.168.82.1
```
Notice the I flag, for -ifscope, on the physical default route.
route change does not seem to work reliably.
* Exit if loading an invalid identity from disk
Previously, if an invalid identity was loaded from disk, ZeroTier would
generate a new identity & chug along and generate a brand new identity
as if nothing happened. When running in containers, this introduces the
possibility for key matter loss; especially when running in containers
where the identity files are mounted in the container read only. In
this case, ZT will continue chugging along with a brand new identity
with no possibility of recovering the private key.
ZeroTier should exit upon loading of invalid identity.public/identity.secret #2056
* add validation test for #2056
It doesn't work.
Not possible to fix with deficient network
stack and APIs.
ZeroTierOne-freebsd # zerotier-cli set 9bee8941b5xxxxxx allowDefault=1
400 set Allow Default does not work properly on FreeBSD. See #580
root@freebsd13-a:~/ZeroTierOne-freebsd # zerotier-cli get 9bee8941b5xxxxxx allowDefault
1
