Releasing 1.1pre14.

Revert "Remove tinc.service, it is not necessary."

This reverts commit 0b6f84f96eeed20a0d771fedb72c0e19941adb7e. Although
systemd does automatically provide a "tinc.slice" when there is only a
tinc@.service template, it doesn't quite work the same way as
tinc.service.

Releasing 1.1pre13.

AutoConnect now only chooses from nodes for which we know an address.

Based partially on work from Rafał Leśniak.

Remove tinc.service, it is not necessary.

Thanks to Alexander Ried for pointing out that if you have
tinc@.service template, systemd will provide a default slice containing
all instances of that template. So "systemctl start tinc" will still do
what we want it to do.

Fix BSD tun device support.

This was broken by a botched merge from the master branch in commit d7f6737.

Releasing 1.1pre12.

Don't check file permissions on Windows during fsck.

Fix starting tinc as a service on Windows.

Don't assume tincd.exe is in the working directory, especially now that
chdir() is called very early. We use GetModuleFileName() instead.

Fix a compiler warning on Windows.

Fix possible read of freed memory when verifying the signature of a file.

Have "tinc fsck" recognize Ed25519PublicKey statements.

Move documentation of invitations to the manual.

Fix the "network" command in tinc shell.

Speed up AutoConnect at startup.

Call periodic_handler() immediately at startup. Also, don't try to
connect to ourself.

Don't call terminate_connection(myself->connection).

It doesn't do anything except give a confusing error message that we are
closing the connection to ourself. Replace it with connection_del().
This also fixes a double free.

Handle special characters in sptps_test only if the --special option is given.

sptps_test treats lines starting with #, ^ and $ specially, in order to
test the SPTPS protocol. However, this should only be done if explicitly
requested, otherwise it can unexpectedly fail.

Add stricter checks for netnames.

When passing a NetName via an invitation, we don't allow any characters
that are unsafe (either because they could cause shells to expand things,
or because they are not allowed on some filesystems).

Also, warn when tinc is started with unsafe netnames.

Use ifconfig_header().

Chdir() to the configuration directory instead of /.

Add a test for tinc-up creation from invitations.

Fix compiler warnings.

Fix gateway parsing in invitation files.

Allow gateways to be specified for routes.

Also improve the variable names, and ensure the % symbols in
%INTERFACE% are properly quoted.

Move some stray #includes.

Generate a tinc-up script from an invitation.

This adds the ability for an invitation to provision an invitee with a
tinc-up script. This is quite strictly controlled; only address configuration
and routes are supported by adding "Ifconfig" and "Route" statements to
the invitation file. The "tinc join" command will generate a tinc-up script
from those statements, and will ask before enabling the tinc-up script.

Document how invitation files work.

This should eventually be merged in to tinc.texi.

Stop using SOL_TCP, SOL_IP and SOL_IPV6.

Instead, use IPPROTO_TCP, _IP and _IPv6. This fixes an issue on OS X where
it didn't create an UDP socket that listened on IPv4.

Fix crash at startup when Device is not specified on OS X.

Fix conditional checking of tun/tap headers on DragonFly BSD.

Fix some compiler warnings from MinGW.

Fix generation of version_git.h for some versions of BSD make.

In order to support VPATH builds, we have to use ${srcdir}/version.c as
the target for the rule that depends on the generation of version_git.h.
When not doing a VPATH build, ${srcdir} expands to ".", so the target
will be "./version.c". However, on some BSDs, make does not understand
that "./version.c" is the same as "version.c", and therefore it doesn't
trigger generating version_git.h when trying to build version.o. (It
works fine if you do a VPATH build, and OpenBSD's make does the right
thing in all cases.)

The trick is to have version.c depend on ${srcdir}/version.c. Of course,
Linux's make knows this is nonsense and will complain about a circular
dependency, so add this rule only on BSD platforms.

Fix a non-working cast to get rid of a compiler warning.

Don't use HAVE_SYSTEM, the autoconf check was removed.

Remove use of strcpy() and sprintf().

Even though they were safe, compilers like to warn about them nowadays.

Don't assume sa.sa_family is a short int.

Because FreeBSD's compiler complained about it.

Add version_git.h and sample-config.tar.gz to CLEANFILES.

Make some platform-specific header checks conditional.

Don't check for linux/if_tun.h on BSD platforms for example.

Remove support for Windows 2000 and anything that doesn't support getaddrinfo().

Remove checks for non-C99 compliant compilers.

Fix version_get.h generation on BSD.

It doesn't like .PHONY rules that are actually doing stuff. So make a really
phony rule that does nothing and depend in it in the version_git.h rule.

Fix typo in Makefile.am.

Use getcwd() instead of get_current_dir_name().

Replace usleep() with nanosleep().

Fix compiling under MinGW.

Remove checks for headers and functions that are in C99.

Make text files Markdown-compatible.

Update .gitignore.

Remove elliptic curve stubs from gcrypt/, add PRF implementation.

Really don't compile getopt*.c if the system provides getopt_long().

Enable silent builds by default.

Cleaner build messages make it easier to spot compiler warnings and errors.
Use make V=1 to get the verbose output back.

# Conflicts:
# configure.ac
# doc/Makefile.am

Update links in the documentation.

# Conflicts:
# doc/tinc.conf.5.in
# doc/tinc.texi
# src/avl_tree.c
# src/avl_tree.h

Explicitly mention that LibreSSL can be used as well.

# Conflicts:
# doc/tinc.texi
# m4/openssl.m4

Update support for BSD tun/tap devices, add support for OS X utun interfaces.

Update "now" after connect() when making outgoing connections.

It could be that address resolution takes a long time, don't let that
count against a connection. This is especially important when using a
nameserver from the VPN.

# Conflicts:
# src/net_socket.c

Never call putenv() with data on the stack.

Even though we are using putenv() here to remove items from the
environment, there is no guarantee that putenv() doesn't add the
argument to the environment anyway. In that case, we have to make sure
that it doesn't go away. We also don't want a memory leak, so keep a
list of things we unputenv()ed around, so we can reuse things.

Thanks to Poul-Henning Kamp for pointing out this problem.

# Conflicts:
# src/process.c

Fix --logfile without a filename on Windows.

On Windows, the log filename now defaults to "tinc.log" in the same
directory as tinc.conf.

# Conflicts:
# src/tincd.c

Support ToS/DiffServ for IPv6 meta and UDP connections.

Also remember ToS/DiffServ priority for each socket individually. This
is a port of commits c72e237 and 042a6c1.

Use iface instead of interface.

This was accidentally added in commit 2f03a5d.

Update THANKS.

Update .gitignore.

Don't compile getopt*.c if the system provides getopt_long().

# Conflicts:
# configure.ac
# src/Makefile.am
# src/tincd.c

Fix typo.

Found by LunarShaddow.

re-arrange include sequence to avoid a mingw introduced bug.
refers: https://www.cygwin.com/ml/cygwin/2012-12/msg00194.html

# Conflicts:
# src/cygwin/device.c

fix typo

Fix for botched cherry-pick commit 60fb230.

Add warnings for bad combinations of Device and Interface.

On Linux, the name of the tun/tap interface can be set freely. However,
on most other operating systems, tinc cannot change the name of the
interface. In those situations, it is possible to specify a Device and
an Interface that conflict with each other. On BSD, this can cause
$INTERFACE to be set incorrectly, on Windows, this results in a
potentially unreliable way in which a TAP-Win32 interface is selected.

# Conflicts:
# src/bsd/device.c

Small fixes for the documentation.

# Conflicts:
# doc/tinc.texi

Clarify that scripts are called synchronously.

# Conflicts:
# doc/tinc.conf.5.in
# doc/tinc.texi

Fix forwarding of edge updates.

Commit e4670fc accidentily prevented ADD_EDGE messages from propagating
in some cases.

Improve performance of edge updates.

Remove forward declaration for do_decrement_ttl.

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
# Conflicts:
# src/route.c

s/broadcast_packet_helper/route_broadcast/

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
# Conflicts:
# src/route.c

Fix DecrementTTL option for packets destined to the local node.

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
# Conflicts:
# src/route.c

Try to reply with node address only when decrementing the TTL.

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>

Fix source IP address for ICMP unreachable packets generated by tinc.

Try to send ICMP unreachable replies from an address assigned to the
local machine, instead of the destination address of the original
packet.

The address is found by looking up the route towards the sender of
the packet that generated the error; in usual configurations, this
is the tinc interface.

This also fixes the traceroute display in mtr when using the
DecrementTTL option.

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
# Conflicts:
# src/route.c

Fix DecrementTTL option.

The option was not actually working, as it could be seen on traceroute or mtr.

The problem is that it was checking if the TTL was < 1 (so equal to 0) before decrementing it.

This meant that a packet with a TTL of 1 was being sent with a TTL of 0 on the VPN, instead of being discarded with the ICMP error message.

Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
# Conflicts:
# src/route.c

Use nostdinc instead of overriding DEFAULT_INCLUDES.

Only check for -fno-strict-overflow if -fwrapv does not work.

Update .gitignore.

Add the ability to sign and verify files.

Merge remote-tracking branch 'mweinelt/tinc-gui' into 1.1

Only add a reflexive address when we're sure it's working.

Use static buffers for recvmmsg(), initialize them only as needed.

As suggested by Michael Tokarev.

Add support for recvmmsg().

Based on a patch from Samuel Thibault and input from Michael Tokarev.

list_delete() already free()s the deleted element.

Don't leave dead outgoing_t's in the outgoing_list.

If an outgoing connection cannot be made because no address is known for
it, it should be removed from the outgoing_list, otherwise it will
prevent it from being re-added later when we do know addresses for it.

Add upnp.h to tincd SOURCES.

This was missing from 513bffe1fee07bcbcb50691e221874adc1507857.

Don't unset validkey when receiving SPTPS handshakes over ANS_KEY.

This fixes a hairy race condition that was introduced in
1e89a63f1638e43dee79afbb18d5f733b27d830b, which changed
the underlying transport of handshake packets from REQ_KEY to ANS_KEY.
Unfortunately, what I missed in that commit is, on the receiving side,
there is a slight difference between req_key_h() and ans_key_h():
indeed, the latter resets validkey to false.

The reason why this is not a problem during typical operation is
because the normal SPTPS key regeneration procedure looks like this:

    KEX ->
    <- KEX
    SIG ->
    <- SIG

All these messages are sent over ANS_KEY, therefore the receiving side
will unset validkey. However, that's typically not a problem in practice
because upon reception of the last message (SIG), SPTPS will call
sptps_receive_record(), which will set validkey to true again, and
everything works out fine in the end.

However, that was the *typical* scenario. Now let's assume that the
SPTPS channel is in active use at the same time key regeneration
happens. Specifically, let's assume a normal VPN data packet sneaks in
during the key regeneration procedure:

    KEX ->
    <- KEX
    <- (SPTPS packet, over TCP or UDP)
    <- KEX (wtf?)
    SIG -> (refused with Invalid packet seqno: XXX != 0)

At this point, both nodes are extremely confused and the SPTPS channel
becomes unusable with various errors being thrown on both sides. The
channel will stay down until automatic SPTPS channel restart kicks in
after 10 seconds.

(Note: the above is just an example - the race can occur on either side
whenever a packet is sent during the period of time between KEX and SIG
messages are received by the node sending the packet.)

I've seen this race occur in the wild - it is very likely to occur if
key regeneration occurs on a heavily loaded channel. It can be
reproduced fairly easily by setting KeyExpire to a short value (a few
seconds) and then running something like ping -f foobar -i 0.01.

The reason why this occurs is because tinc's TX code path triggers the
following:

 - send_packet()
 - try_tx()
 - try_tx_sptps()
 - validkey is false because we just received an ANS_KEY message
 - waitingforkey is false because it's not used for key regeneration
 - send_req_key()
 - SPTPS channel restart (sptps_stop(), sptps_start()).

Obviously, it all goes downhill from there and the two nodes get very
confused quickly (for example the seqno gets reset, hence the error
messages).

This commit fixes the issue by keeping validkey set when SPTPS data is
received over ANS_KEY messages.

Update THANKS file.

Try to ensure we build correctly against various libminiupnpc versions.

Unfortunately, libminiupnpc has a somewhat... "peculiar" approach to
backwards compatibility for their API, where they reserve the right to
make breaking changes when they feel like it, forcing users to resort
to #ifdefs to ensure they use the correct API. Sigh.

Previously, tinc would only build against API versions <= 13, because I
was doing my initial development using miniupnpc-1.9.20140610 which is
the version that ships with Debian. The changes in this commit are
required for tinc to build against more recent versions, from
1.9.20150730 to the latest one at the time of this commit, 1.9.20151026.

Allow tinc to be built with miniupnpc on Windows.

Contrary to what I expected, it so happens that modern versions of MinGW
include an implementation of pthread natively by default, so there is no
need to introduce Win32-specific threading code. This means the only
changes required to make UPnP work on Windows are just build parameter
tuning.

This commit forces MinGW to be built statically. This makes linking
against miniupnpc simpler (otherwise we would have to handle the mess
of dllimport & co.) and it also prevents libwinpthread from being linked
dynamically (which it is by default), as this would require additional
DLLs to be distributed. Since static linking is how tinc is
traditionally built on Windows, I don't expect this to be a big deal.

Add UPnP support to tincd.

This commit makes tincd capable of discovering UPnP-IGD devices on the
local network, and add mappings (port redirects) for its TCP and/or UDP
port.

The goal is to improve reliability and performance of tinc with nodes
sitting behind home routers that support UPnP, by making it less reliant
on UDP Hole Punching, which is prone to failure when "hostile" NATs are
involved.

The way this is implemented is by leveraging the libminiupnpc library,
which we have just added a new dependency on. We use pthread to run the
UPnP client code in a dedicated thread; we can't use the tinc event loop
because libminiupnpc doesn't have a non-blocking API.

Add a new optional dependency on the miniupnpc library.

The miniupnpc library is a lightweight UPnP-IGD client.

http://miniupnp.free.fr/

Contrary to other libraries, this dependency is disabled by default.
This is because the library is somewhat obscure and is only tangentially
useful, so enabling it by default would probably annoy most users.

Make sure the packet source MAC address is always set.

When tinc is used in router mode with a TAP device, Ethernet (MAC)
headers are not present in packets flowing over the VPN; it is the
node's responsibility to fill out this header before handing the
packet over to the TAP interface (which expects such headers).

Currently, tinc fills out the destination MAC address of the packet
(otherwise the host would not recognize the packets, and nothing would
work), but it does not fill out the source MAC address. In practice this
doesn't seem to cause any real issues (the host doesn't care about the
source address), but it does look weird when looking at the packets with
a sniffer, and it also result in the following valgrind warning:

    ==13651== Syscall param write(buf) points to uninitialised byte(s)
    ==13651==    at 0x5C4B620: __write_nocancel (syscall-template.S:81)
    ==13651==    by 0x1445AA: write_packet (device.c:183)
    ==13651==    by 0x118C7C: send_packet (net_packet.c:1259)
    ==13651==    by 0x12B70A: route_ipv4 (route.c:443)
    ==13651==    by 0x12D5F8: route (route.c:971)
    ==13651==    by 0x1152BC: receive_packet (net_packet.c:250)
    ==13651==    by 0x117E1B: receive_sptps_record (net_packet.c:904)
    ==13651==    by 0x1309A8: sptps_receive_data_datagram (sptps.c:488)
    ==13651==    by 0x130A90: sptps_receive_data (sptps.c:508)
    ==13651==    by 0x115569: receive_udppacket (net_packet.c:286)
    ==13651==    by 0x119856: handle_incoming_vpn_data (net_packet.c:1499)
    ==13651==    by 0x10F3DA: event_loop (event.c:287)
    ==13651==  Address 0xffeffea3a is on thread 1's stack
    ==13651==  in frame #6, created by receive_sptps_record (net_packet.c:821)
    ==13651==

This commit fixes the issue by filling out the source MAC address. It is
generated by negating the last byte of the device MAC address, which is
consistent with what route_arp() does.

In addition, this commit stops route_arp() from filling out the Ethernet
header of the packet - this is the responsibility of send_packet(), not
route().

Revert "Cache node IDs in a hash table for faster lookups."

This reverts commit c2319e90b16962fe899bc60abc8af0e2542bb176.

As a general principle, I do not believe it is worthwhile to cache
nodes. Sure, it brings lookup time down from O(log n) to O(1), but
considering that the scalability target of tinc is around 1000 nodes
and log2(1000) is 10, that looks like premature optimization; tree
lookups should already be very fast. Therefore, I believe it makes sense
to remove the cache as a code cleanup initiative.

Use a splay tree for node UDP addresses in order to avoid collisions.

This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).

I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).

The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.

Assume the following topology:

  A <-> B <-> C

Now let's consider the perspective of tincd running on B, and let's
assume the following is true:

 - All nodes are using the 1.1 protocol with node IDs and relaying
   support.
 - Nodes A and C have UDP addresses that hash to the same value.
 - Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
   cache).
 - Node A has a "dynamic" UDP address (i.e. an UDP address that has been
   detected dynamically and cannot be deduced from edge addresses).

Then, before this commit, A would be unable to relay packets through B.

This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.

I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.

The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.

Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.

Avoid undefined behavior.

Left shifts of negative values is undefined in C. This happens a lot in
the Ed25519 code. Cast to unsigned first, then cast the result back to
signed where necessary.

tinc-gui: Properly initialize class attributes for VPN in __init__

tinc-gui: Use ArgumentParser, default to python2