| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
restart problem. Installer probably should NOT mess with the running service, since Linux servers are likely to be production.
|
|
|
|
|
|
|
|
|
|
|
|
problem. Have to test a bit more.
|
|
and clean up service start/stop in installer.
|
|
|
|
configure firewall rules (because we can now).
|
|
|
|
(clean). (And Windows 10, and Windows Server, and ...)
|
|
(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.
|
|
|
|
bootstrapping .app and installer script.
|
|
|
|
|
|
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.
|
|
outside normal RPM channels.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
network now doesn't leave networks in limbo.
|
|
|
|
|
|
|
|
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".
|
|
|
|
|
|
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.
|
|
|
