ZeroTier hasn't been self-updating on Linux since very early versions. We found that many Linux users were using it on servers and really did not want software auto-updating itself independent of their scheduled use of 'yum' or 'apt'.

In 1.1.6+ we have finally developed real Linux packages and our own Linux package repository. The install script we created just adds that repo and installs the package, and once the repo is added it should auto-update along with other Linux packages when you do system package updates. This is expected behavior on Linux for a packaged app.

We also have people working to get this into Fedora/EPEL and Debian upstream but that's another matter, and many users might still prefer our repos since they will be updated more quickly.

MacOSX and Windows have auto-update functionality but we've been sort of gun shy about using it for the same reason. So far our policy has been to keep it around in case we ever have a critical security vulnerability that we need to force-patch ASAP. So far that has not happened.

Right now it's a button we can push. There's a signing key we have that we keep in cold storage for it.

We'd like to revisit the update schedule at some point in the future since auto-updating quickly can be a desirable feature if it's done well. But it's very hard to do well, especially with an app that integrates with the OS the way ZeroTier does. ZeroTier has drivers, services, etc.

BTW we had a couple releases in a row over the last week since we were fixing minor issues with route management and default route override / full tunnel, both of which were new and non-trivial. Hopefully it's calmed down now.

Looks like Chocolatey packaging is easy. Coming soon.

Chocolatey package in review... will post after approval and further testing.

Ahh.. nodeBB ... view source is your friend.

Hmm... so the question is: how does Windows determine a priority list for adapters and which one is 'default?' Answering that question seems more elegant than highjacking DNS.

??? Could this perhaps be helpful?

https://support.microsoft.com/en-us/kb/2526067

@Dashrender Can you go up a level and out of the realm of technical details and explain what you're actually attempting to accomplish? Is this a road warrior use case or something else like inter-site collaboration?

Interesting. I haven't looked deeply into Pertino because my business philosophy is to focus on doing what users want and what makes technical design sense and ignore competition. In fact, during ZT initial design I deliberately did not try any alternatives because I didn't want to "pollute" my headspace.

ZT may not need the DNS hack, since it doesn't use DNS to route traffic. It doesn't need any of that. It does everything a layer down using crypto for authentication and lazy route-learning with automatic switching and preference order. It's like VXLAN over a p2p mesh. It will fall back to WAN-in-WAN-out however if your LAN has rules that prohibit lateral communication... I've seen that in houses that run WiFi switches that do that.

It does seem like the DNS hack would help with the IP ambiguity issue though in mixed deployments, and mixed deployments are what most non-greenfield existing enterprises are going to want because they can't install SDN software on everything... either because they are risk/change averse or because they run a lot of things that are too old/slow/whatever to run it.

Pertino seems to have a lot of enterprise management features we don't have, and may or may not ever build. We've decided to focus intensely upon the "SDN everywhere" problem domain and do it right and that's our bread and butter as they say. We're targeting mobile, IoT, data center, and hybrid cloud as well as distributed teams and other VPN-ish use cases. (And tech hobbyists, hackers, gamers, etc. We've even had someone install ZT on an ARM Linux device in a drone and make the drone switch WiFi networks as it flies... said it worked decently well.)

@scottalanmiller Yes ZT is SDN, basically VXLAN over a P2P network. Here is a brief technical overview: https://www.zerotier.com/misc/2015-09-23_ZeroTier_Tech_Intro.pdf

@hubtechagain E-mail me at [email protected] and we can determine if that would work or not for your use case. (Also helps us decide what to build next even if it won't work.)

Heh... in that case ZT will work fine if they can work around addressing edge cases like the aforementioned. If you are all-in on SDN you just use that as your LAN in which case it all works because it's all just a LAN.

The hairy legacy heterogenous things are the evil ones, but I suspect that's where a good chunk of revenue might be if you could actually do it well.

@dafyre Also wanted to mention: ZT doesn't use DHCP per se. It can do its own IP assignment using its own methods (network controller assigns IPs) or it can let the OS manage it. In the latter case it will pass DHCP packets so if you enable DHCP on the interface it should work if you have a server on the same network. Beware of DHCP + bridging though, since you can get weird route issues.

@Dashrender IPs and online status can be seen through the ZT control panel (https://my.zerotier.com/ and we'll be licensing a self-hosted version of this soon with more features) and I'm not sure what you mean by bottlenecks. If you mean traffic monitoring there are tools like Zabbix (linked above) that do that well and so far detailed stats like that have been out of scope for ZT (but maybe not forever). ZeroTier runs a full p2p mesh so under most conditions a bottleneck has no real meaning... traffic just flows directly from endpoint to endpoint as it normally would but with encryption and stable mobile addressing. It will run as fast as the underlying network (minus a bit of crypto overhead).

Things can also be free forever if you are the product: https://www.youtube.com/watch?v=ldhHkVjLe7A

If someone can donate a Windows RT (ARM) device we can see if we can build for that. Theoretically it should work if you can build normal Windows apps for it as ARM binaries... never messed with it before. But porting the driver might be loads of fun.

@dafyre We'll support earlier iOS if possible... but from what we've read 9 may have must-haves for us. Doing p2p on mobile is not easy at all. Not even a little bit. Our Android port is pretty solid though... I've had it up for months and you can ping my phone on the ZeroTier company LAN whether it's on WiFi or LTE and it switches pretty fast. For testing I played music from my house over LTE while I was driving to work.

I have a bunch of Pi's here that we use for network testing. I could download that image and try it out I suppose.

If MS wants to deal themselves back into the mobile deck, they should do a genuinely convergent phone that runs a real Windows desktop with a little micro HDMI jack on it. Plug in a monitor and wham-o, you have a real computer you can do real things on.

It should use its cached network config and certs -- see the networks.d/<nwid>.conf files, etc.

Does anyone know if this comes up in other situations? Seems like the one-layer-down issue is getting AD to work in a multi-network environment.

Obviously if you go 'all in' with SDN then your private IPs will just work always, but not everyone can do that.