| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
shub-niggurath.zerotier.com:/git/ZeroTierOne into adamierymenko-dev
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
a nasty but obvious bug I introduced into Utils::getSecureRandom.
|
|
things from the original pre-fork tap code base that we will never use.
|
|
|
|
|
|
|
|
Instead package binaries.
|
|
|
|
|
|
COM is pushed with multicast, which makes tremendous sense in retrospect.
|
|
|
|
|
|
|
|
in NetworkActivity using the new authenticated flag in the new DB schema.
|
|
|
|
|
|
|
|
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.
|
|
making an iddb.d directory in the ZeroTier home folder. Also clean up some obsolete cruft from makefiles.
|
|
startup, which is good enough for clients right now. Supernodes will get something else for long-term authoritative identity caching.
|
|
way to save identities, but that can be a different feature. Regular clients do not really need a permanent cache (yet). When/if we do need one we can do it then. Until then it only caused problems.
|
|
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.
|
|
|
|
|
|
want to do tablets eventually.
|
|
think I am gonna go with this one. Seems memory-hard enough to me. I am probably procrastinating by obsessing over it.
|
|
|
|
encrypt and decrypt. Profiling analysis found that Salsa20 encrypt was accounting for a nontrivial percentage of CPU time, so it makes sense to cut this load fundamentally. There are no published attacks against Salsa20/12, and DJB believes 20 rounds to be overkill. This should be more than enough for our needs. Obviously incorporating ASM Salsa20 is among the next steps for performance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
handled correctly.
|
|
|
|
|
