ZeroTier One version 1.0.4 brings several improvements to stability,
connectivity between hosts on the same LAN, and NAT traversal.
Direct connectivity improvements:
- ZeroTier One now opens port mappings using uPnP and/or NAT-PMP
if they are available on your network. These are then made
available to other (1.0.4 or newer) nodes. This should greatly
improve direct connectivity success rates for users on networks
that support port mapping. To build with this option, you must
include ZT_USE_MINIUPNPC=1 on the make path. Pre-build binaries
are included for many common architectures to make this easier.
- A new message has been introduced whereby nodes can "push" IP
address suggestions to other nodes. This is only done to nodes
with whom you have a trust relationship, which right now means
they are members of a network you've joined. The IP addresses
sent include local interface addresses and possibly uPnP mappings
if any are available. When nodes receive pushed IPs, they can
attempt connectivity at these addresses. This greatly improves
connectivity on local LANs, since the old broadcast mechanism
proved too unreliable under many real world scenarios.
- IPv6 addresses are also "pushed" via the aforementioned message,
allowing direct connectivity over IPv6 if both hosts have an
IPv6 address.
- Some of the aggressive port-scanning NAT-t behavior has been
removed, since this occasionally triggered intrusion alarms on
some networks and proved ineffective in the field. uPnP will be
a much bigger win, and is less "hacky."
- The rate of (tiny) UDP keepalive packet generation was slightly
increased. We were as surprised as you to learn that there are
many NAT routers in the wild with timeouts as short as 20 seconds
even though the RFC stipulates that they should be no shorter
than two minutes (120 seconds).
All of these connectivity improvements rely upon a new message
introduced with 1.0.4, so they'll only work between 1.0.4 nodes.
Older methods of connectivity establishment will continue to work
with earlier versions.
Platform-specific improvements:
- Many improvements have been made to Windows support and stability.
The NDIS6 driver is now used exclusively. If you have ports that
use NDIS5, these will automatically be re-created using the NDIS6
driver. You may see a "select this network's type" notification
after 1.0.4 upgrade for this reason.
- The dependency on the external "devcon.exe" binary on Windows has
been completely removed in favor of internal direct calls to the
Windows setup API to add and remove network ports. These are done
via dynamically loaded instances of the system setup DLLs to use
the most recent setup API code on your system for improved
compatibility.
- This version is tested with Windows 10 release, and was confirmed
to work on a clean install.
- The ARM32/Raspbian build is now back to using Debian Wheezy for
library backward compatibility (binary build only).
- The Mac icon is now a bit smaller to look better in the dock.
- The ui/ subfolder is now distributed with the Linux binary installer
and packages. This means Linux users can navigate to the UI at
http://127.0.0.1:9993/ and enter their authtoken.secret to use
the GUI locally. (This port could also be accessed via SSH port
forwarding or other mechanisms to administrate graphically from a
remote system.)
Other improvements:
- The new beta SQLite-backed controller microservice found in
controller/ and built with the ZT_ENABLE_NETWORK_CONTROLLER=1 make
option is now in a much more "working" state. Feel free to give
it a try! If you tried it before, delete controller.db before
starting the new version.
- A few tweaks were made to the path selection logic in the hope of
eliminating some flaky network behavior reported by users.
The next version of ZeroTier One will focus on performance and memory
footprint reduction, and may also include perfect forward security/secrecy
(a.k.a. PFS) once our design is finalized and reviewed.
(2) Go back to timestamp as certificate revision number. This is simpler
and more robust than using the network revision number for this and
forcing network revision fast-forward, which could cause some peers
to fall off the horizon when you don't want them to.
and go ahead and bump version to 1.0.4.
For a while in 1.0.3 -dev I was trying to optimize out repeated network controller
requests by using a ratcheting mechanism. If the client received a network config
that was indeed different from the one it had, it would respond by instantlly
requesting it again.
Not sure what I was thinking. It's fundamentally unsafe to respond to a message
with another message of the same type -- it risks a race condition. In this case
that's exactly what could happen.
It just isn't worth the added complexity to avoid a tiny, tiny amount of network
overhead, so I've taken this whole path out.
A few extra bytes every two minutes isn't worth fretting about, but as I recall
the reason for this optimization was to save CPU on the controller. This can be
achieved by just caching responses in memory *there* and serving those same
responses back out if they haven't changed.
I think I developed that 'ratcheting' stuff before I went full time on this. It's
hard to develop stuff like this without hours of sustained focus.
_networks is usually quite small, using binary search on a vector might be faster comapred to std::map.
This is especially true when using uClibc++, which uses a list.
Multiple statements in a sqlite3_prepare_v2 is not usable. Only
the first statement will be executed.
Since the schema now uses 'ON DELETE CASCADE', there's only
one statement needed.
If multiple statements are needed, there should be either multiple
sqlite3_prepare_v2 calls be used or the sqlite3_exec function.
The foreign keys have 'ON DELETE CASCADE' to simplify the removal
of networks etc. (controller code)
Some unique constraints are replaced with a multi column primary
key.
To update an existing database:
* install updated binaries
* stop service
* sqlite3 controller.db .dump | \
egrep '((^PRAGMA)|(^BEGIN)|(^INSERT)|(^COMMIT))' | \
grep -v 'schemaVersion' > data.sql
* mv controller.db controller.db.backup
* start service
* stop service
* sqlite3 controller.db < data.sql
* start service
After many months of intense development, ZeroTier is proud to release version
1.0.3 of ZeroTier One.
This version focuses on under-the-hood and network level improvements to
prepare the way for more user-facing improvements in the months to come, as
well as new products built around the ZeroTier core.
1.0.3 contains a large number of changes, so we're not going to push it out
via our auto-update mechanism yet. We're going to update the download links
on the web site and let users try it out for a while first. If problems are
found, we'll do a 1.0.4 before we push it out to existing installations.
--
Important note for Linux users: we've decided to stop pushing auto-updates for
Linux, and this version's official Linux binaries are built without update
checking enabled. Linux is used mostly on servers, and based on user feedback
we've found that most users don't like anything auto-updating outside of the
normal package management channels. Instead, we'll be working over the next
few months to get ZeroTier One included in a number of upstream Linux
distributions. That way you'll be able to 'apt-get' or 'yum' install it and
stay up to date that way. Auto-updates will remain for Macintosh and Windows
users until/unless we can move to 'app store' deployment on those platforms.
--
Now for the change list. It's a big one!
NEW FEATURES and IMPROVEMENTS
* Client support is in place for preferred relays on a per-network basis.
This allows you to define statically assigned nodes that act as relays for
indirect communication and connection setup for communication between peers
on a given virtual network. If defined, they'll be used in preference to
supernodes for this purpose. If they're offline, ZeroTier will fall back to
global supernodes. This will require support on the web control panel for
most users to use.
* This version sends NAT "keepalive" packets every 20 seconds, which is
similar to the behavior of most SIP phones. This should improve reliability
behind NATs with short timeouts and certain cheap consumer NAT devices.
* Improvements have been made to NAT traversal to traverse more symmetric
NAT configurations, and to rate limit traversal attempts to avoid looking
like a port scan.
* New direct paths are now confirmed prior to use. This should improve
reliability in cases where a NAT traversal attempt "half succeeds" by
preventing the use of direct links that aren't actually usable.
* A new geo-located TCP tunneling fallback implementation should improve
performance for heavily firewalled users who can't use UDP.
* ZeroTier now uses remotely reported accounts of your external IP address
to detect changes in your network connectivity instead of relying on
"fingerprinting" of the OS-level local network environment. This should
improve reliability in cases where external routers have dynamic IPs or
when changing between networks with different external IPs but similar
internal addressing schemes. This should also improve reliability for
use within virtual machines, since the external link address might change
but the VM's link addresses will not.
* We've eliminated the old Unix domain socket (or named pipe on Windows)
control bus in favor of a local HTTP JSON API. It runs on 127.0.0.1
port 9993 and can be accessed via standard HTTP. This improves
interoperability with scripts and other tools and allows us to use
HTML5 for the desktop UI component. See README.md in the service/
subfolder of the source tree for JSON API documentation.
* The old Qt GUI has been dropped in favor of a React-based HTML5 UI. The
code for this is found in ui/, and if ui/ is present in the ZeroTier
home folder the JSON API HTTP server will serve it on 127.0.0.1/9993.
The Windows and Mac UIs are now web control wrappers which access this
UI locally and automate the process of token lookup and login.
PACKAGING / INSTALLATION IMPROVEMENTS
* The Macintosh version is now packaged as a .pkg file instead of the old
.app that would download its components and bootstrap itself. Several
Mac users had problems with this, so we made it a package instead.
* The Windows installer now includes a cleaner driver installation module
that installs the driver as part of the main MSI file instead of spawning
a subprocess.
BUG FIXES
* Windows now comes with an updated NDIS6 Ethernet tap device driver.
If you still have the old NDIS5 driver installed you'll keep using it,
so if you want to switch to the NDIS6 driver uninstall your old version
and do a fresh install of the new one. NDIS5 is deprecated, so we are
hoping an NDIS6 driver will fix a number of difficult to reproduce
issues that some Windows users have reported. It will also likely
improve performance.
* Fixed a "pseudo" memory leak related to the old auto-update code. The
amount of "committed" (but not used) memory would increase over time.
Since this was not actual used memory it didn't cause real problems,
but the issue is gone now.
* A very rare threading deadlock was fixed.
* Fix for Linux installer that would falsely recognize systemd on some
Ubuntu systems.
DEEP UNDER THE HOOD
* This version has been heavily refactored at the source code level! The
node/ subfolder now contains the core ZeroTier network virtualization
engine without any OS-specific or transport-specific code. This is in
preparation for future plans around embedded devices, etc. There is now
a public C-level API in include/ZeroTierOne.h that defines an interface
to the node core.
* A new network controller implementation is in 1.0.3 based on SQLite and
the local JSON API control bus. IT HAS NOT BEEN HEAVILY TESTED YET, so we
do not recommend using it in production until the next version. You are
welcome to experiment with it.
Fixed VirtualNetworkConfigFunction (creating array to send to Java)
Fixed the creating InetAddress instead of InetSocketAddress in virtual network config callback
Just delete the local reference rather than do an array delete. Array delete was causing a crash on loading network config files. Deleting the local ref works fine, though, as it still lets the JVM garbage collecter know that the native code is done with the array
(1) Yes, you *can* create a mixed 32/64 bit Windows MSI installer that installs drivers. All you have to do is... umm... create individual sub-MSI files for each driver (one for 32, one for 64) and then package those in the main MSI files as "chained" MSI installers. Each of these must only be considered a prerequisite on 32 or 64 bit machines, respectively.
(2) Upgrade Advanced Installer version, add rules to uninstall NDIS6 tap device on uninstall.
(3) Fix IE issue in UI code.
Version 1.0.2 brings experimental FreeBSD support. It has ONLY been tested
on FreeBSD 10 on an x64 system, and should be considered alpha for this
platform for now.
This version is not going to be pushed out to the entire world via software
update, and the binary version distributed for other platforms via the
zerotier.com web site will remain 1.0.1 as there are no other meaningful
user-facing changes. This is just an interim release to let FreeBSD users
try it out. If you find bugs, please enter them on GitHub or do a pull
request and fix them yourself.
Version 1.0.2 brings experimental FreeBSD support. It has ONLY been tested
on FreeBSD 10 on an x64 system, and should be considered alpha for this
platform for now.
This version is not going to be pushed out to the entire world via software
update, and the binary version distributed for other platforms via the
zerotier.com web site will remain 1.0.1 as there are no other meaningful
user-facing changes. This is just an interim release to let FreeBSD users
try it out. If you find bugs, please enter them on GitHub or do a pull
request and fix them yourself.
This version is mostly a bug fix release. It fixes a bug that could cause
the service to crash on Windows while running the GUI application. It also
contains a number of fixes to the Linux installer and Linux support for
systemd-based init systems.
It also includes a minor tweak to the multicast algorithm. Version 1.0.0
sent multicasts in a deterministic order, while this version randomizes
the order. The vast majority of users will notice nothing, but this may result
in superior coverage for service announcements on very large networks. It's
a hard variation to test, so we're releasing like this to gather information
from users about the effect. Nothing will change on small networks, and
ordinary multicast functions like ARP and NDP should be unaffected.
The next version will likely focus on additional improvements to Microsoft
Windows support, since there are several known Windows issues in need of
attention. We're working on an NDIS6-based Tap driver that should address
the driver issues experienced by a small number of Windows 7 users.
This should not affect most users, but on large networks it should cause service
announcements to work a lot better. This is the result of a prolonged discussion
with a user about the visibility of game servers on a large network. The old
multicast algorithm was de-facto randomized due to its distributed nature, while
the new algorithm is more deterministic. This will restore some randomization
beyond limit-overflow conditions.
It won't affect small networks at all.
ZeroTier 1.0.0 brings a number of under the hood improvements and bug
fixes. These include but are not limited to:
* A simpler, faster multicast algorithm that places full burden
for multicast propagation on the sender. This results in better
fairness without CPU-intensive signature/verify on every packet,
lower latency for intra-data-center SDN operations, and avoids
distributed burdens that are intrinsically unfriendly to mobile
clients subject to wake frequency limits and battery life
constraints. In the future this may be augmented to allow
optimized delivery to multiple recipients at the same site via
federation.
* Significant code reorg to move toward mobile support (iOS, Android)
and future SDK packaging.
* A number of efficiency and stability improvements.
* Bug fixes for Linux and ARM users.
* Improved NAT traversal, including limited support for port
numbering scheme guessing to traverse some symmetric NATs.
Upgrade from 0.9.x is not required but is strongly recommended. Older
clients using the old multicast algorithm are presently supported via
legacy hooks, and these may go away at some point in the future. We'll
monitor the status of the network and try to keep legacy support around
as long as people need it, but it'll probably be pulled once 95%+ of
clients are 1.0.0 or newer.
The next versions will bring further bug fixes, improved user experience,
more enterprise-grade features for intra-data-center use, and more!
the current content of detached-network-test. This is ready for another
test in 'headless' mode.
Merge branch 'detached-network-test' into adamierymenko-dev
This version is being tagged and bagged, despite the fact that it's not
going to be released and won't be merged into master until 1.0.0 is ready.
It contains several Linux build fixes, a fix for a unix domain socket resource
leak, and build fixes for the Raspberry Pi.
The primary focus of this version is better integration with the
Microsoft Windows operating system.
Virtual networks should now be detected as "real" networks. For
each network, a message box should pop up the first time the network
is detected and classified allowing the user to choose its services
and security designation. On Windows 7 this is "work," "home," or
"public." On Windows 8 it's a simple choice of whether or not to
enable file and printer sharing and other services.
Several bugs have been fixed. Among these are a Windows threading
issue, several minor threading deadlock issues that could manifest
if rapidly adding and removing networks, and a command line interface
issue. The network list now shows the network MAC address as well,
a UI oversight in previous versions. A vectorized SSE implementation
of Salsa20 is now included for improved encrypt/decrypt performance.
The sending of low-TTL "firewall opener" packets has been disabled
in this version, since they may not be necessary and may harm NAT
traversal in some configurations. We will measure the effectiveness
of NAT traversal and see if this change improves performance in the
field.
Finally, this version obsoletes both the Tokyo and Sydney supernodes
in favor of a single larger supernode in Singapore. This decision was
made on the basis of bandwidth costs-- both Tokyo and Sydney are
significantly more expensive. We'd like to keep the basic service free,
so keeping bandwidth costs for relaying low is important. Since NAT
traversal works well and is constantly being improved, most users will
not see a speed decrease from this. Some Chinese users may see
improved performance since Singapore may be closer than Tokyo to many
Chinese cities.
The next major releases will focus on better Macintosh platform integration,
further improvements to NAT traversal, and UI improvements.
now show up as *real* networks and prompt the user to set their
location and firewall status (public, private, home/work, etc.).
The hack used to achieve #2 should not be examined by children or those
suffering from epilepsy or heart conditions.
This version fixes several bugs including an issue with networks that have
EtherType filtering disabled, a file permission issue that affected non-English
versions of Windows, a multicast propagation bug that caused multicasts to
be dropped more often than they should be, and an issue with IP auto-configuration.
It also introduces experimental support for bridging between physical and virtual
networks, a much-requested and powerful ability that's been planned from the start.
ZeroTier One can now replace the functionality of ordinary VPNs, link multiple
offices into a single LAN, and connect virtual machine backplanes in the cloud to
physical networks at home, among other things.
Bridging support isn't "officially" out yet, since the web UI part is still
in development. But when that is done, an official announcement will be
made on the blog and users can try it out. So far bridging has only
been tested under Linux with the Linux kernel's native bridging driver.
YMMV on other platforms. Try it out and let us know by filing bugs at GitHub
or e-mailing them to "contact@zerotier.com".
Version 0.9.0 adds a network-wide toggle for blanket broadcast (ff:ff:ff:ff:ff:ff), contains changes for compatibility with the new web site and netconf server code, and most importantly introduces unique non-conflicting MAC address schemes on a per-virtual-network basis.
The MAC address change is necessary to support bridging, which is the next major feature to be added. It's not absolutely required, but it makes sure that things work properly in the (probably very rare) case that two virtual networks happen to be directly or indirectly bridged together.
The MAC change means that 0.9.0 is a required update. Clients not updating will find themselves unable to communicate with older versions. The underlying protocol is the same, but MAC address resolution and routing will not work properly. Those running binary releases will be updated automatically, while those running from source must download and rebuild.
This version also fixes two minor security issues, including one involving file permissions on non-English Windows versions.
This version fixes a few more issues with TCP tunneling including GitHub issue #63.
It also adds automatic announcement and location of peers on physical LANs (GitHub
issue #56) which should greatly improve performance if you happen to be on the same
LAN or WiFi network as another peer. It can take 60 seconds or so for this to occur,
but it should.
This, quick on the heels of 0.8.0, fixes the fact that TCP tunneling was
broken. :)
There was a bug that only manifested in some cases, and not on my testnet.
I took the opportunity to clean up some of that logic generally. I need a
better testnet, but that will have to wait until we exit beta and hopefully
I can earn a little bit of money off this. A better testnet will require
a big beefy virtualization box or two to run hundreds to thousands of KVMs.
Also fixed a tiny cosmetic issue on Windows. Other than that no changes.
This version introduces a major new feature requested by several users,
both via the user survey and otherwise: TCP tunneling.
If you are not able to communicate over UDP/9993, ZeroTier One will switch to
TCP connections to ZeroTier's supernodes. This is always slower than UDP, but
will allow you to communicate behind all but the most extremely restrictive
firewalls. This TCP traffic travels over port 443 and looks like HTTPS (SSL)
traffic (though it isn't), since that port is almost always open.
This also fixes several minor bugs and attempts to improve the robustness of
Windows tap driver management. Several users have reported spurious issues
with the Windows tap device, though I was unable to reproduce any of these with
clean VMs. (Tried Windows 7 and 8.1, both x86 and x64. No luck.) But I tried
to beef up the tap code anyway in the hopes of catching it. It now tries a lot
harder to make sure the tap is up and running.
There was some significant under the hood refactoring in support of TCP, so
this was a non-trivial change.
I bumped the version to 0.8 to indicate that more and more features are being
crossed off the list as we approach 1.0 and exit from beta. After this, the next
major feature will be LAN announcement to find direct paths to peers on the
same physical LAN. But assuming that 0.8.0 goes smoothly, I am going to divert
attention to the web site. A new design is coming that is much cleaner, sharper,
and easier to use.
Thank you all for all your excellent feedback! We're well on the way to a killer
product that makes conventional VPNs and other kludges obsolete.
Version 0.7.2 marks the first release of ZeroTier One for Windows. Binaries will be
released to a few select testers at first, then to the whole world. Installation from
MSI and auto-update appear to be working. So far Windows 7 and 8 and Windows Server
2008 or newer are supported. Vista has issues so it's not supported at the moment,
and may not be since nobody seems to use it (according to Google Analytics).
This version contains fixes to Linux installation and deployment and adds a
new supernode in Tokyo, Japan. It also has a working Windows installer, though
a bit more testing is going to take place before Windows binaries are
actually released.
Version 0.7.0 commemorates public beta binaries now being in the wild for Mac
and Linux platforms, though this actually happened a few days ago with 0.6.14.
This version fixes two bugs. First, the Linux installer/updater now supports
both systemd and regular SysV init. It will detect which your distro uses at
install/update time and install the zerotier-one service accordingly.
Secondly, this fixes an issue that caused the service to always show ONLINE
in the GUI or 'zerotier-cli info' even if there was no net connection. The
online status should be more reliably reported now.
This version adds persistence of *nix device names (where possible), and fixes
a possible crash in Topology.cpp that was introduced in a previous revision.
It also adds a new supernode located in Singapore!
This version ties up some stuff that remains in the core before binary release.
It adds support for direct interface IP enumeration on *nix systems, as well
as a fix for IPv6 link-local addresses on OSX. This also contains some cleanup
in Peer and some improvements to help detect and route around dead or unreachable
supernodes.
Getting close!
This version fixes a minor NAT traversal issue. In the past, NAT-t links had a timeout
but otherwise were preserved. This version makes them more ephemeral and invalidates
them on sleep/wake or changes in network configuration or environment.
This is because many NAT setups are very fragile with regard to hole punches, so the
past stickiness of links caused dead links to persist too long and break connectivity
between peers.
This is about 75% of what needs to be done to greatly improve robustness. The other 25%
involves detecting failed links or failed relays.
This version is also almost done for the Windows platform, moving us even closer to
binary release.
Not a significant release for OSS users, but this version marks a significant
increase in workitude on the Windows platform. A properly and officially
signed x64 driver is also included. x86 drivers and more Windows work including
Qt UI are coming soon.
(1) Add a bunch of tedious type casts to eliminate unnecessary compiler warnings on Windows X64 builds.
(2) Some EthernetTap work to integrate Windows custom IOCTL for multicast group lookup (not done quite yet).
(3) Dump some more info in selftest to make sure our Windows path lookup functions are returning sane results.
Another release leading up to official binary releases... not much to the core,
but quite a bit of work on the UI, installation, and such.
This version will build and run on OSX 10.6 while previous versions would fail
due to a missing getifmaddrs() function.
This version contains no significant changes to the engine itself, just to
the installer, the GUI, and packaging and such. It's all stuff for prep for
the big release, which is fast approaching!
New versions will be coming fast and furious for a bit as bugs get fixed and
testing is done in prep to the first binary release.
This version fixes a problem with WAN path discovery and a possible security
issue in PacketDecoder. (see previous comments)
(1) The changes to path learning in the two previous releases were poorly thought out,
and this version should remedy that by introducing PROBE. This is basically a kind of
ECHO request and is used to authenticate endpoints that are not learned via a valid
request/response pair. Thus we will still passively learn endpoints, but securely.
(2) Turns out there was a security oversight in _doHELLO() that could have permitted...
well... I'm not sure it was exploitable to do anything particularly interesting since
a bad identity would be discarded anyway, but fix it just the same.
This version contains few changes that are visible to users building from source.
It contains an almost-complete version of the Qt-based GUI in ZeroTierUI, though
this is still a work in progress. It also contains the software update infrastructure,
which is not yet enabled by default but does basically work. Some cleanup and
dead code removal has also occurred.
The next release will probably be the first binary release with auto-update and a
full UI experience for Linux and Mac. Windows will follow later, as more work has
to be done on the Windows port.
This version fixes a recurrent gremlin in the tap driver for Mac. If you are
having this issue, you should reinstall the tap.
If you're already running ZT1, shut it down (sudo killall zerotier-one) and
then do:
sudo kextunload /Library/Application\ Support/ZeroTier/One/tap.kext
This should unload the old version. Then type 'sudo make install-mac-tap' in
the ZT1 source home directory and the new version will be installed. ZT1 will
load the module again when it next starts.
In addition to a fix, I am now distributing tap binaries and it is no longer
built in the default Makefile. This is because Apple's in the midst of some
changes that have made building it somewhat difficult.
Another note for Mavericks users:
The first time you use ZT1, you will get a popup about unsigned kernel
extensions. This will vanish once we're out of beta and have signing keys
and signed drivers.
Other changes in this version:
* Minor improvement to Utils::getSecureRandom
* Bug fixes and a small change to certificates of membership for private
networks, which now appear to be working very well!
* Stubbed out messages for auto-update, which will be done in-band via
the ZT1 protocol. Not implemented yet.
This version removes the peer DBM present in earlier releases. It is not necessary for
regular clients and has been a source of problems.
There is a long-term identity cache that can be enabled by making a directory called
"iddb.d" in the home folder and restarting ZT1. This is probably something only our
supernodes would need, since regular nodes can easily WHOIS peers they've forgotten
about.
On shutdown, the peer database is dumped to disk. It's then restored on startup.
Peers that have not been used in a while are cleaned out, so this keeps this data
set small.
A DBM may re-appear later if it's needed, but for now it was YAGNI.
Version 0.6.0 marks the transition of ZeroTier One from ALPHA to BETA.
Major updates to the web site and binary packages for MacOS and Linux
are coming soon, followed by Windows soon thereafter.
This version contains a number of changes including:
* Speed improvements to encryption
* A new much-improved identity algorithm, which unfortunately requires an
identity regeneration. This should happen automatically, and should be
the last time for a good long while assuming there's nothing wrong with
what's here.
* Cleaned up the Network::Config mess in the code, factored out Config
into its own NetworkConfig class.
* Lots of work to support private networks, which are still in testing.
Concurrent with the web site update will be another minor release to
include any fixes there.
* Some changes to the protocol for better future-proofing.
* Netconf support for ARP caching parameters configurable on per-network
basis.
You must update to stay connected to the network; this version will not
talk to 0.5.0. After this, I'm going to be much more reluctant to make
incompatible changes.
Whew. This is a big one. More of a marathon than a sprint.
First, four big things:
1) This version breaks backward compatibility with all prior versions.
It's in alpha, I can do that.
2) The port has changed from 8993 to 9993 to mark this change. Probably
not necessary but why not? Also 8993/UDP turned out to be used by some
enterprise LDAP thingy, which doesn't matter much either but again why
not?
3) This version, unlike previous versions, does NOT auto-join the Earth
network. Soon there will be more than one net, and not everyone is going
to want to get dumped on a flat global LAN right out of the box. To
join Earth use the command line interface:
sudo zerotier-cli join bc8f9a8ee3000001
4) Finally, you will get a different IP on Earth. The whole cryptosystem
has changed and we're not going to bother with continuity issues in
alpha testing.
So what's changed? See the blog:
http://blog.zerotier.com/post/62991430345/alpha-zerotier-one-network-is-down-briefly
The net should be up shortly after this commit. If there are any issues,
0.5.0 will be rapidly followed by 0.5.1. :-) Otherwise the next sprint
will be finishing up support for private networks. Then it's off to the
races with BETA, then Windows. (Decided to move into beta before Windows
in all likelihood.)
Changes:
* It now builds and runs on Windows with Visual Studio 2012. Windows is
not ready for prime time yet though for several reasons, so no Windows
release yet. If you're brave you can try to DIY, but the driver is
not signed yet either. Windows is a work in progress still.
* Networks now pull their ethernet type whitelist from the netconf master
instead of having it hard-coded. (Prep for network mgmt.)
* Netconf master now sends name and description of networks so this can
be used to set Windows network display names.
* A couple minor bug fixes here and there, nothing major.
* No protocol changes that break compatibility.
In addition to a lot of Windows port work that isn't finished yet (and doesn't
affect the *nix platforms at all), this version contains quite a bit of multicast
cleanup and code simplification.
I also pulled rate limits for now, as it seems to be causing problems. More testing
on the testnet is going to be needed.
This version fixes problems with locating the 'ip' command on Gentoo
and possibly other Linux systems, and a problem that could cause a
crash if EthernetTap was unable to locate one of the commands it
invokes to configure IP information on tap devices.
The code also now builds on Windows. It doesn't run yet, but it's a
step. Windows port is in full swing.
Finally, the multicast rate limit defaults were raised a little. More
testing is needed here, and real world measurments.
This version fixes problems with locating the 'ip' command on Gentoo
and possibly other Linux systems, and a problem that could cause a
crash if EthernetTap was unable to locate one of the commands it
invokes to configure IP information on tap devices.
The code also now builds on Windows. It doesn't run yet, but it's a
step. Windows port is in full swing.
Version 0.4.2 is largely a cleanup release. Changes are minor:
* Programatically replace libcrypto's random number generator with our
own (using /dev/urandom or Windows CAPI) since libcrypto's RNG likes
to use uninitialized memory as one of its entropy sources. This causes
massive floods of valgrind (debugger) errors during memory error
profiling analysis.
* Clean up some other code to eliminate valgrind errors.
Valgrind now runs on Linux with only one error. This error is in
EthernetTap and is a false positive.
* ZeroTier protocol design and core network virtualization engine, ZeroTier One service, React web UI, packaging for most platforms, kitchen sink...<br>
Adam Ierymenko / adam.ierymenko@zerotier.com
* Java JNI Interface to enable Android application development, and Android app itself (code for that is elsewhere)<br>
Grant Limberg / glimberg@gmail.com
## Contributors
* A number of fixes and improvements to the new controller, other stuff.<br>
Kees Bos / https://github.com/keesbos
* Debugging and testing, OpenWRT support fixes.<br>
Moritz Warning / moritzwarning@web.de
* Several others made smaller contributions, which GitHub tracks here:<br>
ZeroTier One creates flat virtual Ethernet networks of almost unlimited size. [Visit ZeroTier on the web](https://www.zerotier.com/) for more information.
ZeroTier is a software defined networking layer for Earth.
This code is presently in **ALPHA** testing. That means that the protocol spec may change in incompatible ways, and it certainly has bugs. Testers should "git pull," rebuild, and restart fairly often. If things mysteriously stop working, do that.
It can be used for on-premise network virtualization, as a peer to peer VPN for mobile teams, for hybrid or multi-data-center cloud deployments, or just about anywhere else secure software defined virtual networking is useful.
See BUILDING.txt and RUNNING.txt for instructions. It currently builds on Mac and Linux. A Windows port is coming soon. Nice packages/installers and auto-update are also coming when alpha transitions to beta.
ZeroTier One is our OS-level client service. It allows Mac, Linux, Windows, FreeBSD, and soon other types of clients to join ZeroTier virtual networks like conventional VPNs or VLANs. It can run on native systems, VMs, or containers (Docker, OpenVZ, etc.).
Note that this won't work if your firewall does not allow outbound UDP. It mustallow UDP conversations on port 8993 at a minimum.
Visit [ZeroTier's site](https://www.zerotier.com/) for more information. You can also download professionally packaged binary installers/packages for a variety of supported OSes there if you don't want to build ZeroTier One from source.
At present there is only one virtual LAN and you are dumped there by default. It's called Earth, and is exactly what it sounds like. The ability to create and join additional networks is coming soon. Once you're on, visit [earth.zerotier.net](http://earth.zerotier.net/) to see your Earth LAN IP address and other information.
### Building from Source
**Security warning:** You read that right. ZeroTier One places your computer on an absolutely open global Ethernet party line. Please ensure that you are up to date on your OS patches and we recommend turning off unnecessary services. Also be sure that anything else you are sharing is password protected provided you don't want to share it: printers, iPhoto and iTunes shares, etc.
For Mac, Linux, and BSD, just type "make" (or "gmake" on BSD). You won't need much installed; here are the requirements for various platforms:
ZeroTier One is licensed under the GNU General Public License version 3. You are free to use, modify, or redistribute it under the terms of that license. If you would like to embed ZeroTier One in a closed source product or create a closed source derivative product, contact ZeroTier Networks LLC.
* Mac: Xcode command line tools, and [Packages](http://s.sudre.free.fr/Software/Packages/about.html) if you want to build an OSX .pkg installer ("make mac-dist-pkg"). It should build on OSX 10.7 or newer.
* Linux: gcc/g++ or clang/clang++ (Makefile will use clang by default if available.)
* FreeBSD (and other BSD): C++ compiler (G++ usually) and GNU make (gmake).
Check out the [blog](http://blog.zerotier.com/) for announcements, in-depth articles, and related thoughts. There is also a [Google group](https://groups.google.com/forum/#!forum/zerotier-one-users) for questions and discussion.
Each supported platform has its own *make-XXX.mk* file that contains the actual make rules for the platform. The right .mk file is included by the main Makefile based on the GNU make *OSTYPE* variable. Take a look at the .mk file for your platform for other targets, debug build rules, etc.
----
**FAQ**
Windows, of course, is special. We build for Windows with Microsoft Visual Studio 2012 on Windows 7. A solution file is located in the *windows* subfolder. Newer versions of Visual Studio (and Windows) may work but haven't been tested. Older versions almost certainly will not, since they lack things like *stdint.h* and certain STL features. MinGW or other ports of gcc/clang to Windows should also work but haven't been tested. Build steps for Windows are a bit more complicated. For the moment you are on your own there.
**Q:** What can I do with this?
**A:** For starters, try opening iTunes if you have it installed. If others are also online and sharing their collections, you might see them. If you have any games that run over a LAN (except those that require IPX), try those. What else can you think of to do on a completely flat, open network? Games? Collaborative software development? Remote debugging? Transferring files using simple drive shares? Sharing your desktop printer to someone on another continent? Use your imagination.
Mobile versions are in progress. They don't work yet, and in any case only the glue code will be included in this repository. The full mobile apps are in private repositories on our own git server.
**Q:** Why do I get an IP address in the 27.0.0.0 or 28.0.0.0 range? And why does a lookup claim these addresses belong to the U.S. Department of Defense?
**A:** Short answer: because IPv4 needs to die. Long answer: the Earth network assigns IPv4 IPs from these ranges. They do in fact belong to the DOD, but they are *not* routed to the open Internet. The DOD owns them but uses them internally for private networks. As a result, there is nothing *technically* wrong with "bogarting" these for our own private network. It's considered bad practice, but if you want a private address space in IPv4 that is unlikely to overlap other private address spaces (like 10/8 and 192.168/16), it's the only way. [Cellular carriers](http://www.androidcentral.com/sprint-internet-dept-defense-and-you) and [cable companies](http://www.dslreports.com/forum/r25679029-Why-is-my-first-hop-to-a-DoD-assigned-IP-address-) frequently do the same thing.
### Supported Platforms
**Q:** Is IPv6 supported?
**A:** Yes. IPv6 link-local addresses (those in the fe80::/10 block) are auto-assigned and should work fine. No other IPv6 addresses are assigned *yet*, but there are plans to do interesting things in this area in the future.
CPU architecture shouldn't matter unless it's smaller than 32-bit or something really bizarre like a "middle-endian" processor. We have reports of ZeroTier One running on arm32, arm64, and MIPS. It builds and runs out of the box on Raspberry Pi, BeagleBone, BananaPi, and other ARM-based developer/hobbyist boards.
**Q:** I don't want a giant Ethernet party line. Can I leave it and create private LANs instead?
**A:** Yes, soon. A GUI to configure such things is in development. But for now there's only Earth.
ZeroTier is written in C and C++ (C++03 / ISO/IEC 14882:2003) and uses data structures and algorithms from the C++03 STL. We do not use any C++11 features (yet), since we want to support a few old and embedded platforms that don't have C++11 compilers. You *will* require a compiler and headers new enough to support 64-bit integers (long long) and the *stdint.h* header. The latter could also be faked by adding defines for things like *uint32\_t*, *int64\_t*, etc.
**Q:** Are you going to charge for this?
**A:** Public virtual LANs will remain free. We intend to charge for private networks in some way, but the exact model is TBD. Other cloud-supported paid features are also TBD.
Typing "make selftest" will build a *zerotier-selftest* binary which unit tests various internals and reports on a few aspects of the build environment. It's a good idea to try this on novel platforms or architectures.
**Q:** What's a supernode?
**A:** Supernodes are nodes run by ZeroTier Networks that orindary users use to find one another and communicate until/unless they can perform NAT traversal and connect directly. They run the exact same software as everyone else. The only thing that really makes a supernode special is that it's designated as such.
### Running
**Q:** Can I run a supernode?
**A:** No, not at the moment, and there would be no benefit to doing so.
Running *zerotier-one* with -h will show help.
**Q:** Will my local firewall rules apply to ZeroTier One traffic?
**A:** ZeroTier creates a virtual Ethernet tap device (zt# on Mac and Linux) that emulates a wired Ethernet port. If your firewall applies to *all* network ports, it will filter traffic through this port as well. If it applies only to the primary interface, it may not. See your OS's firewall documentation, as different OSes and flavors thereof have slightly different configurations in this regard.
On Linux and BSD you can start the service with:
**Q:** Can you see my traffic? What about other users? Can you sniff the LAN?
**A:** No. All unicast (direct computer to computer) traffic is encrypted end-to-end (even if it's being relayed), and the ZeroTier virtual LAN behaves like a LAN with a secure enterprise-grade switch that does not allow unicast conversations to be sniffed. Multicast and broadcast traffic will of course be seen by many recipients, but that's the idea.
sudo ./zerotier-one -d
**Q:** What about privacy? Does this hide my location on the network?
**A:** ZeroTier is not a connection anonymizer. Other than encryption, it doesn't do anything special to hide your identity or network location. If you want strong privacy protection there are already very advanced tools like [Tor](https://www.torproject.org) for that, and this isn't trying to duplicate their functionality. At the same time, ZT does not do anything special to harm your privacy either. It's not spyware or snoop-ware.
A home folder for your system will automatically be created.
**Q:** Is this designed to replace IP, BGP, IPv6, routers, etc.?
**A:** No. Its purpose is to act as a collaboration tool, a VPN alternative, a network mobility tool, a testbed for the development of software that takes advantage of fully open networking, a virtual LAN party for gamers, and so on, but it's not intended (or able) to replace the core of the Internet.
The service is controlled via the JSON API, which by default is available at 127.0.0.1 port 9993. We include a *zerotier-cli* command line utility to make API calls for standard things like joining and leaving networks. The *authtoken.secret* file in the home folder contains the secret token for accessing this API. See README.md in [service/](service/) for API documentation.
**Q:** Can I bridge this to a physical port and plug in an Xbox, PlayStation, etc.?
**A:** Not currently, as foreign Ethernet frames are not forwarded. This may be possible in a future version.
Here's where home folders live (by default) on each OS:
----
**Status**
* Linux: /var/lib/zerotier-one
* BSD: /var/db/zerotier-one
* Mac: /Library/Application Support/ZeroTier/One
* Windows: \\ProgramData\\ZeroTier\\One (That's for Windows 7. The base 'shared app data' folder might be different on different Windows versions.)
*What works:*
* Network auto-configuration via JSON API with identity based authentication and encryption
* End-to-end encryption with automatic key exchange
* Ethernet multicast with implicit social propagation (though the algorithm will certainly be getting tweaked as we go)
* IPv4 ARP works (see MulticastGroup.hpp for details)
* IPv6 neighbor discovery protocol works, thus IPv6 link-local addressing on the ZeroTier device also works
* mDNS (though if the LAN gets big you will not see everyone, just people nearby on your implicit social graph)
* IP-level multicast ought to "just work," though it may take up to a minute or so for a new join to propagate
* NAT traversal works pretty well, at least behind relatively sane unrestrictive firewalls/routers. You can see this by pinging another node and watching, after a few seconds, the latency drop dramatically since you're no longer relaying. If it doesn't your firewall might block such things. Additional NAT traversal strategies are coming.
* Changes in your local network configuration are generally detected and will cause peers to be re-acquired.
Running ZeroTier One on a Mac is the same, but OSX requires a kernel extension. We ship a signed binary build of the ZeroTier tap device driver, which can be installed on Mac with:
*Known immediate issues:*
* Multiple network support is in but there is no interface to configure it, hence it is useless. But in alpha it'll be nice to shove everyone onto "Earth" in order to stress test that little "almost unlimited size" boast.
* There is no multiple-launch protection yet and multiple instances on the same system do not work well due to route conflicts. Take care that zerotier-one is not running before launching it again. The command "sudo killall zerotier-one" is helpful.
* Sometimes ZeroTier One doesn't like to terminate when asked nicely. This is related to issues with the tap device closing down properly. If it hangs around after a TERM signal, send it a KILL (9) signal.
* The locally bound UDP port isn't configurable yet. It's 8993 by default.
* Known security issues:
* There is no rate limit for multicast. Please be nice during alpha testing and don't flood.
* There is no filtering. Whether or not to try to do port-level filtering is not yet decided, as technically the local OS firewall and OS service configuration should do this and ZeroTier is not about re-inventing wheels. But certain things *will*need to be filtered by ZT1 itself. These include certain ICMP and ICMPv6 messages: router advertisement, router solicitation, source redirect, etc. DHCP and BOOTP should probably also be filtered at a minimum.
* ARP and IPv6 NDP want extra security measures to prevent poisoning and spoofing. The best mechanism is being researched.
* If a supernode goes down, this takes quite a while to be detected and things will go dead. Fast recovery from relay failure is in the works.
* If by a one in 2^40 chance two people generate the same ZeroTier address, this is currently not handled. It's unlikely and also hard (as in cryptographically hard) to do intentionally. See comments in Identity.cpp for details.
sudo make install-mac-tap
*What doesn't work and might not work for a while, if ever:*
* Only ARP, IPv4, and IPv6 frames are allowed. The ability to permit other ethertypes on user-created networks may be added later to allow things like old games that use IPX or private networks to remote administer weird hardware.
* Bridging of the ZeroTier device to other networks will not work, and may never. This is TBD.
* VLAN tagged frames will not work and probably never will, as higher level network provisioning handles that concept.
This will create the home folder for Mac, place *tap.kext* there, and set its modes correctly to enable ZeroTier One to manage it with *kextload* and *kextunload*.
----
We recommend using our binary packages on Windows, since there are several prerequisites such as a tap driver that must be installed on the system *and* in the home folder.
ZeroTier virtual networks are identified by 16-digit hexadecimal network IDs, while devices are identified by 10-digit addresses. To get your address run:
sudo zerotier-cli status
(Use ./zerotier-cli if you're running it right from your build folder.)
You should see something like:
200 info ########## ONLINE #.#.#
That 10-digit hex code is you. It's derived via a one-way proof of work function from your cryptographic public key. Your public key can be found in *identity.public* in ZeroTier's home folder, while *identity.secret* contains your full identity including the secret portion of the key pair.
(The identity files define your device's *identity*. Moving them to another system will move that identity. Be careful when cloning virtual machines that have identities stored on them. If two devices have the same identity, they'll "fight" over it and you won't know which device will receive network packets.)
If you want to do a quick test, you can join [Earth](https://www.zerotier.com/earth.html). It's a global public network that anyone can join. Type:
sudo zerotier-cli join 8056c2e21c000001
Then:
sudo zerotier-cli listnetworks
At first it'll be in *REQUESTING\_CONFIGURATION* state. In a few seconds to a minute you should see something like:
200 listnetworks 8056c2e21c000001 earth.zerotier.net ##:##:##:##:##:## OK PUBLIC zt0 ##.##.##.##/##
Earth will assign you an IP address in the "unofficially available" globally unrouted 28.0.0.0/7 IP block so as to avoid conflicts with local networks. (Your networks can use any IP scheme, or can even leave IP addresses unmanaged.) Once you get an IP, you should be able to ping something:
ping earth.zerotier.net
Go to [http://earth.zerotier.net/](http://earth.zerotier.net/) to see a short little welcome page that will tell you your IP and Ethernet MAC address.
Earth is a public place. If you don't want to stick around run:
sudo zerotier-cli leave 8056c2e21c000001
The network (and associated interface) should be gone.
Networks are created and administrated by network controllers. Most users will want to use our hosted controllers. Visit [our web site](https://www.zerotier.com/) for more information. Later in this README there are brief instructions about building ZeroTier One with network controller support for those who want to try running their own.
Macintosh and Windows installers also install a GUI application.
### Installing
We don't have a "make install" rule quite yet. On Linux you can type:
make installer
This will build a binary that, when run, will install ZeroTier One on most current Linux distributions. We also have RPM and DEB build files in *ext/installfiles/linux* that wrap this installer in packages for RedHat/CentOS and Debian/Ubuntu derived distributions. If *rpmbuild* is present on the system, the RPM will be built. If *dpkg-deb* is present, the DEB package will be built.
On Mac the best way is to install [Packages](http://s.sudre.free.fr/Software/Packages/about.html) and use:
make mac-dist-pkg
This builds a .pkg file that can be installed.
BSD has no installer yet. We're working on it.
Linux/BSD and Mac installations have an *uninstall.sh* file in their ZeroTier home folder that cleanly removes ZeroTier One from the system. Run this with:
sudo /path/to/ZeroTier/home/folder/uninstall.sh
Windows installers are insane. We build our .MSI installers with [Advanced Installer Enterprise](http://www.advancedinstaller.com). The Advanced Installer project file is in *ext/installfiles/windows*. To avoid lasting psychological trauma we recommend leaving Windows installers alone and using the pre-built Windows binaries on our web site.
### Using ZeroTier One in Docker Containers
To run the ZeroTier One service in a Docker container, run it with "--device=/dev/net/tun --cap-add=NET_ADMIN". This will allow ZeroTier One to open a "tap" virtual network port inside the container.
Alternately, you can use Ethernet bridging to bridge the *docker0* device on your system to a ZeroTier virtual network. This allows you to run ZeroTier One on the host and bridge the entire Docker network backplane to a virtual network or other hosts.
We're working on better "official" Docker support. In the meantime there is a [user-contributed project here](https://github.com/davide/docker-zerotier).
### Building with Network Controller Support
**Warning: as of beta version 1.0.3 the new network controller is not heavily tested. We recommend waiting for 1.0.4 to deploy this in production.**
Network controllers are nodes responsible for issuing configurations and certificates to members of ZeroTier virtual networks. Most users won't need to run their own, so this code is by default not included in the ZeroTier One binary.
You can build a network controller on Linux or Mac with:
make ZT_ENABLE_NETWORK_CONTROLLER=1
This will build a version that contains the Sqlite-backed network controller and associated extensions to the JSON local service control API. You will need the development headers for sqlite3 installed. On Mac these ship as part of Xcode, while on Linux they'll be found in packages for the various distributions.
See the JSON API documentation in [service/](service/) for more information about how to control controllers.
### Troubleshooting
For most users, it just works.
If you are running a local system firewall, we recommend adding a rule permitting UDP port 9993 inbound and outbound. If you installed binaries for Windows this should be done automatically. Other platforms might require manual editing of local firewall rules depending on your configuration.
The Mac firewall can be founder under "Security" in System Preferences. Linux has a variety of firewall configuration systems and tools. If you're using Ubuntu's *ufw*, you can do this:
sudo ufw allow 9993/udp
On CentOS check */etc/sysconfig/iptables* for IPTables rules. For other distributions consult your distribution's documentation. You'll also have to check the UIs or documentation for commercial third party firewall applications like Little Snitch (Mac), McAfee Firewall Enterprise (Windows), etc. if you are running any of those. Some corporate environments might have centrally managed firewall software, so you might also have to contact IT.
ZeroTier One peers will automatically locate each other and communicate directly over a local wired LAN *if UDP port 9993 inbound is open*. If that port is filtered, they won't be able to see each others' LAN announcement packets. If you're experiencing poor performance between devices on the same physical network, check their firewall settings. Without LAN auto-location peers must attempt "loopback" NAT traversal, which sometimes fails and in any case requires that every packet traverse your external router twice.
Users behind certain types of firewalls and "symmetric" NAT devices may not able able to connect to external peers directly at all. ZeroTier has limited support for port prediction and will *attempt* to traverse symmetric NATs, but this doesn't always work. If P2P connectivity fails you'll be bouncing UDP packets off our relay servers resulting in slower performance. Some NAT router(s) have a configurable NAT mode, and setting this to "full cone" will eliminate this problem. If you do this you may also see a magical improvement for things like VoIP phones, Skype, BitTorrent, WebRTC, certain games, etc., since all of these use NAT traversal techniques similar to ours.
If you're interested, there's a [technical deep dive about NAT traversal on our blog](https://www.zerotier.com/blog/?p=226). A troubleshooting tool to help you diagnose NAT issues is planned for the future as are uPnP/IGD/NAT-PMP and IPv6 transport.
If a firewall between you and the Internet blocks ZeroTier's UDP traffic, you will fall back to last-resort TCP tunneling to rootservers over port 443 (https impersonation). This will work almost anywhere but is *very slow* compared to UDP or direct peer to peer connectivity.
### License
The ZeroTier source code is open source and is licensed under the GNU GPL v3 (not LGPL). If you'd like to embed it in a closed-source commercial product or appliance, please e-mail [contact@zerotier.com](mailto:contact@zerotier.com) to discuss commercial licensing. Otherwise it can be used for free.
Loaded 20 of 599 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.