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.
This version adds a draft of the multicast rate limiting architecture. A
few minor bugs are also fixed. The Linux version builds in debug mode for
now.
In keeping with the wild west alpha phase of this software, this version is
a major departure from 0.3.0 and an upgrade is required.
The protocol hasn't changed much, but the system of network membership, network
IDs, and network configuration bootstrapping has changed dramatically.
The mechanism for network autoconfiguration is now in-band, via the ZeroTier
protocol itself, rather than using an HTTP API. This simplifies the code and
allows us to use a consistent system of encryption and authentication.
To accomodate this change, network IDs now contain in their most significant
40 bits the ZeroTier address of a node responsible for overseeing the addressing
of participating network members. The remaining bits are free, so each network
controller (netconf node) can control up to 2^24 networks. The code for the
netconf service is in /netconf-service, but for ordinary users there's not much
need to look at it or use it. It's just there to be open source.
The system for network membership tracking is also revamped. For open networks
like Earth this doesn't matter, but for closed networks membership is now driven
by something called a membership certificate that is signed by the controlling
node in the network. There's still work to be done here, so private network
support isn't fully baked yet. But public open networks work fine.
Nodes still join "Earth" by default. The ID for Earth has changed from 1 to
6c92786fee000001 (hex). This means that old 0.3.0 clients and older will not
be able to communicate with 0.4.0 as their network IDs will not match.
The new certificate-based network membership system scales better than the old
HTTP API system and will support some pretty amazing features. Stay tuned!
For now just update and relaunch. You should get the same IPv4 address you
had before.
The second big change is zerotier-cli. Try running it as root (or after
copying the auth file to the path it tells you about when you first run it)
with 'help' as a command.
