| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
within a version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
new-style binary serialized meta-data representation.
|
|
|
|
|
|
|
|
1.1.3 (dev)
|
|
|
|
add a legacy hack for older clients working with clusters.
|
|
|
|
Version 1.0.5 is a very minor release. It includes a new build of the Windows
device driver that supports Windows Vista and 2008 Server, and a fix to prevent
an issue that could occur when updating Linux installations from old pre-1.0.3
versions to 1.0.3 or 1.0.4.
It also includes a few very minor fixes and improvements to the controller code,
which doesn't affect most users.
This second commit just bumps version.h. :)
|
|
interaction,
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.
|
|
|
|
|
|
|
|
disabled for older netconf servers to avoid race. Also add some comments.
|
|
|
|
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.
|
|
new frame to known-to-be-old peers.
|
|
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.
|
|
|
|
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.
|
