Use the ChaCha-Poly1305 cipher for the SPTPS protocol.
The main reason to switch from AES-256-GCM to ChaCha-Poly1305 is to remove a
dependency on OpenSSL, whose behaviour of the AES-256-GCM decryption function
changes between versions. The source code for ChaCha-Pol1305 is small and in
the public domain, and can therefore be easily included in tinc itself.
Moreover, it is very fast even without using any optimized assembler, easily
outperforming AES-256-GCM on platforms that don't have special AES instructions
in hardware.
Remove everything GPL that is not copyright Guus Sliepen, update copyright statements.
Thanks to faithful use of revision control systems, especially git, it has been
relatively easy to find those parts of tinc that were contributed by others. A
large part of that code was not useful for the MeshLink library anyway
(advanced configuration options, privilege dropping and chrooting), the
remaining features contributed by others have been removed (most notably
Brandon Black's improvements related to UDP packet loss and reordering, Etienne
Dechamps' type 2 MTU probe replies, Florian Forster's interface binding code,
Michal Tokarev's support for tunnelserver mode). Support for LZO has been
removed, since it is a GPL library (unless a separate license agreement with
Oberhumer.com is made).
Saverio Proto [Sat, 5 Apr 2014 10:45:35 +0000 (12:45 +0200)]
tinc_start() - skeleton of the API call. The function starts the main tinc thread where the tinc logic will be. We pass the confbase because an application may participate in multiple VPNs at the same time (to be discussed further)
Saverio Proto [Thu, 3 Apr 2014 14:01:29 +0000 (16:01 +0200)]
Successfully compile the libmeshlink library with autotools and compile the sample application against it. Some code from tincctl was copied to libmeshlink.c to avoid redefinition of main in tincctl.c
Saverio Proto [Tue, 1 Apr 2014 15:35:56 +0000 (17:35 +0200)]
Dirt in quick hack Makefile.am to compile a couple of new file.
Start writing libemeshlink.[ch] to implement the library interface.
Trying to keep existing datastructures.
Guus Sliepen [Sun, 9 Mar 2014 14:32:10 +0000 (15:32 +0100)]
Handle a disconnecting tincd better.
- Try to prevent SIGPIPE from being sent for errors sending to the control
socket. We don't outright block the SIGPIPE signal because we still want the
tinc CLI to exit when its output is actually sent to a real (broken) pipe.
- Don't call exit() from top(), and properly detect when the control socket is
closed by the tincd.
Guus Sliepen [Fri, 7 Feb 2014 15:34:08 +0000 (16:34 +0100)]
Handle errors from TAP-Win32/64 adapter in a better way.
Before, the tapreader thread would just exit immediately after encountering the
first error, without notifying the main thread. Now, the tapreader thead never
exits itself, but tells the main thread to stop when more than ten errors are
encountered in a row.
Guus Sliepen [Thu, 30 Jan 2014 16:10:30 +0000 (17:10 +0100)]
Use addresses learned from other nodes when making outgoing connections.
Before, when making a meta-connection to a node (either because of a ConnectTo
or because AutoConnect is set), tinc required one or more Address statements
in the corresponding host config file. However, tinc learns addresses from
other nodes that it uses for UDP connections. We can use those just as well for
TCP connections.
Guus Sliepen [Wed, 29 Jan 2014 16:17:59 +0000 (17:17 +0100)]
Don't ask questions if we are not running interactively.
When creating invitations or using them to join a VPN, and the tinc command is
not run interactively (ie, when stdin and stdout are not connected or
redirected to/from a file), don't ask questions. If normally tinc would ask for
a confirmation, just assume the default answer instead. If tinc really needs
some input, just print an error message instead.
In case an invitation is used for a VPN which uses a netname that is already in
use on the local host, tinc will store the configuration in a temporary
directory. Normally it asks for an alternative netname and then renames the
temporary directory, but when not run interactively, it now just prints the
location of the unchanged temporary directory.
Guus Sliepen [Fri, 24 Jan 2014 15:09:32 +0000 (16:09 +0100)]
Test two tinc daemons using network namespaces.
Testing multiple daemons connecting to each other on the same computer is
usually difficult, because connections to local IP addresses will bypass most
of the network stack. However, recent versions of Linux support network
namespaces, which can isolate network interfaces. We use this to isolate the
virtual interface of the daemons from each other, so we get the behaviour as if
the daemons were each running on their own machine. This can also be used for
more complicated tests (including those with firewall rules) without disturbing
the real network setup of the host computer.