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

tinc-gui: Fix GetListCtrl method name in SuperListCtrl

wxPython wrongly expects camelcase method names, this however
is against PEP8

tinc-gui: Update Node object to correctly parse responses

The application was expecting a different respoonse from tinc
and wouldn't properly it, and thus not start at all.

tinc-gui: Reformat codebase according to PEP8

Fix a few memory leaks in the CLI found by AddressSanitizer.

Fix struct node_status_t.

Although not a problem for tinc internally, the size of the struct was 12
bytes instead of 4, causing some problems when interpreting the value
received from tincd by the CLI.

Replace bare if statements with AS_IF in configure.ac.

Optionally install systemd service files.

If --with-systemd is given when running the configure script, two
systemd service files will be installed. There is a template
tinc@.service, which can be used to control individual instances of
tinc. For example:

systemctl enable tinc@foo

Will create an instance for tinc with netname foo. There is also a
tinc.service, which can be used to start and stop all instances at once.

Add -I m4 back to ACLOCAL_AMFLAGS.

In commit b7b5d51, AC_CONFIG_MACRO_DIRS([m4]) was added to configure.ac,
which is the current proper way of including the m4 directory. However,
old versions of autoconf ignore it and need the -I m4 statement in
Makefile.am. Both the old and new way of indicating that the m4/
directory should be included can coexist.

Fix invalid checksum generation.

Use equation 3 given in RFC 1624 and the UpdateTTL() example function given
RFC 1141.

# Conflicts:
# src/route.c

In sssp_bfs(), never try to update myself.

Do not access e->to->prevedge if not defined

In some cases - mostly when e->to == myself the prevedge is set to NULL,
causing invalid memory access. In rare cases this may lead to malformed mst
or segfaults.

Use AC_CONFIG_MACRO_DIR() instead of _DIRS().

The former is guaranteed to work with autoconf 2.58 and later, and we
don't have multiple m4 directories anyway.

Fix the PRF function when compiling without OpenSSL.

Prevent tinc from forgeting e->local_address

If ADD_EDGE came from tinc version 1.0.x local_address.sa.sa_family is set to 0.
If it came from tinc version 1.1.x forwarded for older verion it will be 255 - AF_UNKNOWN.

Make sure we do not allocate new edge when talking to old nodes and the same edge already exists

When tinc gets ADD_EDGE from older versions it will allocate
new edge in protocol_edge.c:189 due to missed case in lines 149-171 where
local_address is not defined.

Make subnet caches static.

Included missing names.h

Use AC_CONFIG_MACRO_DIRS([m4]).

Remove unused code that caused warnings about an uninitialized variable.

Removed double break;

Fix undefined behaviour when left-shifting signed integers.

Found by -fsanitize=undefined.

Call sockaddrfree(&e->local_address) in free_edge() instead of exit_edges().

The proper place to clean up resources of objects is in their
destructor. This makes sure proper cleanup when edge_del() is called as
well. At exit, free_edge() is called on all edges by free_edge_tree(),
which is called by exit_nodes().

Coalesce two if statements that check for the same thing.

fix musl compatibility

Let configure include sys/if_tun.h when testing for netinet/if_ether.h
to detect the Kernel/libc header conflict on musl.

After this patch, configure will correctly detect netinet/if_ether.h as
unusable and the subsequent compilation will not attempt to use it.

Conflicts:
src/have.h

Don't #include OpenSSL headers when compiling without OpenSSL.

Cleanup local_address in protocol_edge.c

In line 131 local_address has been defined,
but the memory was never freed on return.

Cleanup edges stored in edge_weight_tree on exit

protocol_edge.c: 131 defines local_address using str2sockaddr

str2sockaddr() allocates memory which has to be freed on exit.

Fixed 2 leaks in setup_myself()

setup_outgoing_connection: log to LOG_DEBUG on if no known address

With AutoConnect = yes, tinc tries to establish connections to known hosts.
However, you could have set no Address for this host, which is perfectly fine
(as long as there is at least one bootstrap node with an address or a local
discovered node already part of the network)

So log this to LOG_DEBUG

(read|append)_config_file: log open errors as LOG_DEBUG

In a "decentrally managed vpn" it is very likely that host config
files for some reachable nodes do not exist. Currently, tinc
fills the logs with "Cannot open config file" messages.

This commit changes the log level to LOG_DEBUG so
syslog doesn't get filled by default.

Protect against callbacks removing items from the io tree.

The definition of the splay_each() macro is somewhat complicated for
syntactic reasons. Here's what it does in a more readable way:

  for (splay_node_t* node = tree->head; node;) {
    type* item = node->data;
    splay_node_t* next = node->next;

    // RUN USER BLOCK with (item)

    node = next;
  }

list_each() works in the same way. Since node->next is saved before the
user block runs, this construct supports removing the current item from
within the user block. However, what it does *not* support is removing
*other items* from within the user block, especially the next item.
Indeed, that will invalide the next pointer in the above loop and
therefore result in an invalid pointer dereference.

Unfortunately, there is at least one code path where that unsupported
operation happens. It is located in ack_h(), where the authentication
protocol code detects a double connection (i.e. being connected to
another node twice). Running in the context of a socket read event, this
code will happily terminate the *other* metaconnection, resulting in its
socket being removed from the io tree. If, by misfortune, this other
metaconnection happened to have the next socket FD number (which is
quite possible due to FD reuse - albeit unlikely), and was part of the
io tree (which is quite likely because if that connection is stuck, it
will most likely have pending writes) then this will result in the next
pending io item being destroyed. Invalid pointer dereference ensues.

I did a quick audit of other uses of splay_each() and list_each() and
I believe this is the only scenario in which this "next pointer
invalidation" problem can occur in practice. While this bug has been
there since at least 6bc5d626a8726fc23365ee705761a3c666a08ad4 (November
2012), if not sooner, it happens quite rarely due to the very specific
set of conditions required to trigger it. Nevertheless, it does manage
to crash my central production nodes every other week or so.

Fix typo in tinc.texi.

Fix crash is sptps_logger().

Unfortunately, sptps_logger() cannot know if s->handle is pointing to a
connection_t or a node_t. But it needs to print name and hostname in
both cases. So make sure both types have name and hostname fields at the
start with the same offset.

Fix alignment of output of sptps_speed.

Fix receiving SPTPS data in sptps_speed and sptps_test.

The sptps_receive_data() was changed in commit d237efd to only process
one SPTPS record from a stream input. So now we have to put a loop
around it to ensure we process everything.

Fix warnings about missing return value checks.

In some harmless places, checks for the return value of ECDSA and RSA
key generation and verification was omitted. Add them to keep the
compiler happy and to warn end users in case something is wrong.

Fix autoconf check for function attributes.

GCC warns when a function attribute has no effect. The autoconf check
turns warnings about attributes into errors, therefore thinking that
they did not work. The reason was that the test function returned void,
which is not suitable for checking both __malloc__ and
__warn_unused_result__.

Fix missing return value caused by the previous commit.

Don't try to relay packets to unreachable nodes.

It is not unusual for tinc to receive SPTPS packets to be relayed to
nodes that just became unreachable, due to state propagation delays in
the metagraph.

Unfortunately, the current code doesn't handle that situation correctly,
and still tries to relay the packet to the unreachable node. This
typically ends up segfaulting.

This commit fixes the issue by checking for reachability before relaying
the packet.

Fix invalid pointer use in get_my_hostname().

clang-3.7 warnings surfaced an actual bug:

invitation.c:185:5: error: address of array 'filename' will always evaluate to 'true'
      [-Werror,-Wpointer-bool-conversion]
        if(filename) {
        ~~ ^~~~~~~~

The regression was introduced in 3ccdf50beb6b2d3f2730bdc66006b43190537cde.

Fix wrong format string type in send_sptps_tcppacket().

This issue was found through a clang-3.7 warning:

protocol_misc.c:167:46: error: format specifies type 'short' but the argument has type 'int'
      [-Werror,-Wformat]
        if(!send_request(c, "%d %hd", SPTPS_PACKET, len))
                                ~~~                 ^~~
                                %d

Don't set up an ongoing connection to myself.

It is entirely possible that the configuration file could contain a
ConnectTo statement refering to its own name; that's a reasonable
scenario when one deploys semi-automatically generated tinc.conf files.

Amusingly, tinc does not like that at all, and actually sets up an
outgoing_t structure to myself (which obviously makes no sense). This is
mostly benign, though it does result in non-sensical "Already connected
to myself" messages every retry interval.

However, that also makes things blow up in close_network_connections(),
because there we delete the entire outgoing list and *then* the myself
node, which still has a reference to the freshly deleted outgoing
structure. Boom.

Fix crashes when trying unreachable nodes.

timeout_handler() calls try_tx(c->node) when c->edge exists.
Unfortunately, the existence of c->edge is not enough to conclude that
the node is reachable.

In fact, during connection establishment, there is a short period of
time where we create an edge for the node at the other end of the
metaconnection, but we don't have one from the other side yet.
Unfortunately, if timeout_handler() runs during that short time
window, it will call try_tx() on an unreachable node, which makes
things explode because that function is not prepared to handle that
case.

A typical symptom of this race condition is a hard SEGFAULT while trying
to send packets using metaconnections that don't exist, due to
n->nexthop containing garbage.

This patch fixes the issue by making try_tx() check for reachability,
and then making all code paths use try_tx() instead of the more
specialized methods so that they go through the check.

This regression was introduced in
eb7a0db18ea71a44999d6a37b4b179dac0ed9bc7.

Update copyright notices.

Set the CLOEXEC flag on the umbilical socket.

Use socketpair() instead of pipe() for the umbilical.

This prepares for a possible conversion of the umbilical socket to a
control socket.

Don't write log messages to the umbilical pipe if we don't detach.

If we run in the foreground and are started by the CLI, this would
otherwise cause the first few log messages to appear twice.

Ensure "tinc start" knows if the daemon really started succesfully.

We do this by creating an umbilical between the CLI and the daemon. The
daemon pipes log messages to the CLI until it starts the main loop. The
daemon then cuts the umbilical. The CLI copies all the received log
messages to stderr, and the last byte indicates whether the daemon
started succesfully or not, so the CLI can exit with a useful exit code.

Fix check for LOCALSTATEDIR accessibility for the CLI.

The CLI does not need write access to the directory where the PID file
is stored, it just needs to be able to read the PID file.

Allocate temporary filenames on the stack.

This gets rid of xasprintf() in a number of places, and removes the need
to free() the temporary strings. A few potential memory leaks have been
fixed.

Allow dumping a list of outstanding invitations.

This dumps the name of the invitation file, as well as the name of the
node that is being invited. This can make it easier to find the
invitation file belonging to a given node.

Add "list" as an alias for "dump" in the CLI.

Quit with an error message if ioctl(TUNSETIFF) fails.

It is possible that opening /dev/net/tun works but that interface
creation itself fails, for example if a non-root user tries to create a
new interface, or if the desired interface is already opened by another
process. In this case, the ioctl() fails, but we actually silently
ignored this condition.

If LOCALSTATEDIR is inaccessible, store the pid and socket files in the configuration directory.

The compile time local state directory is usually /var or
/usr/local/var. If this is not accessible for some reason, for example
because someone ./configured tinc without --localstatedir and
/usr/local/var does not exist, or if tinc is started by a non-root user,
then tinc will fall back to the directory where tinc.conf is stored.
A warning is logged when this happens.

Don't log seqno failures in sptps_verify_datagram().

This function is not used for normal traffic, only when a packet from an
unknown source is received and we need to check against candidates. No
failures should be logger in this case; if the packet is really not
valid this will be logged by handle_incoming_vpn_data().

Add source of SPTPS errors to log messages.

Add newline at end of precomp_data.h and sc.h.

Fix src/Makefile.am for *BSD.

Apparently the BSDs don't like $(srcdir) but want to see ${srcdir} in
their rules.

Remove info-in-builddir option from AM_INIT_AUTOMAKE().

This option is not supported by older, but still widely used versions of
automake. The drawback is that when doing multiple VPATH builds in a
row, the info manual may mention incorrect paths, but it doesn't affect
the executables at all.

Fix check for public key in invite-join.test.

Small fix to test/invite-join.test, comparing no-longer-existing
ECDSAPublicKey does not make sense.

Fix direct UDP communciation with pre-relaying 1.1 nodes.

try_tx_sptps() gives up on UDP communication if the recipient doesn't
support relaying. This is too restrictive - we only need the other node
to support relaying if we actually want to relay through them. If the
packet is sent directly, it's fine to send it to an old pre-node-IDs
tinc-1.1 node.

Don't parse node IDs if the sending node doesn't support them.

Currently, tinc tries to parse node IDs for all SPTPS packets, including
ones sent from older, pre-node-IDs tinc-1.1 nodes, and therefore doesn't
recognize packets from these nodes. This commit fixes that.

It also makes code slightly clearer by reducing the amount of fiddling
around packet offset/length.

Fix SPTPS condition in try_harder().

A condition in try_harder() is always evaluating to false when talking
to a SPTPS node because n->status.validkey_in is always false in that
case. Fix the condition so that the SPTPS status is correctly checked.

This prevented recent tinc-1.1 nodes from talking to older, pre-node-ID
tinc-1.1 nodes.

The regression was introduced in
6056f1c13bb37bf711dff9c25a6eaea99f14d31f.

Don't pollute the system header directory namespace.

Since commit 13f9bc1ff199bea46d3dde391a848f119e2cc0f0, tinc passes the
-I. option to the preprocessor so that version_git.h can be found during
out-of-tree ("VPATH") builds.

The problem is, this option also affects the directory search for files
included *from* system headers. For example, on MinGW, unistd.h contains
the following line:

  #include <process.h>

Which, due to -I. putting the tinc directory at the head of the search
order, results in tinc's process.h being included instead of the file
from MinGW. Hilarity ensues.

This commit fixes the issue by using -iquote, which doesn't affect
system headers.

Make sure the MIN() macro is defined.

On MinGW this is not automatically the case, thereby breaking the build.

Merge remote-tracking branches 'dechamps/sptpsrestart' and 'dechamps/keychanged' into 1.1

Don't send KEY_CHANGED messages if we don't support the legacy protocol.

KEY_CHANGED messages are only useful to invalidate keys for non-SPTPS nodes;
SPTPS nodes use a different internal mechanism (forced KEX) for that purpose.
Therefore, if we know we can't talk to legacy nodes, there's no point in
sending them these messages.

Proactively restart the SPTPS tunnel if we get receive errors.

There are a number of ways a SPTPS tunnel can get into a corrupt state.
For example, during key regeneration, the KEX and SIG messages from
other nodes might arrive out of order, which confuses the hell out of
the SPTPS code. Another possible scenario is not noticing another node
crashed and restarted because there was no point in time where the node
was seen completely disconnected from *all* nodes; this could result in
using the wrong (old) key. There are probably other scenarios which have
not even been considered yet. Distributed systems are hard.

When SPTPS got confused by a packet, it used to crash the entire
process; fortunately that was fixed by commit
2e7f68ad2b51648b89c4b5c61aeb4cec67c2fbbb. However, the error handling
(or lack thereof) leaves a lot to be desired. Currently, when SPTPS
encounters an error when receiving a packet, it just shrugs it off and
continues as if nothing happened. The problem is, sometimes getting
receive errors mean the tunnel is completely stuck and will not recover
on its own. In that case, the node will become unreachable - possibly
indefinitely.

The goal of this commit is to improve SPTPS error handling by taking
proactive action when an incoming packet triggers a failure, which is
often an indicator that the tunnel is stuck in some way. When that
happens, we simply restart SPTPS entirely, which should make the tunnel
recover quickly.

To prevent "storms" where two buggy nodes flood each other with invalid
packets and therefore spend all their time negotiating new tunnels, we
limit the frequency at which tunnel restarts happen to ten seconds.

It is likely this commit will solve the "Invalid KEX record length
during key regeneration" issue that has been seen in the wild. It is
difficult to be sure though because we do not have a full understanding
of all the possible conditions that can trigger this problem.

Trivial: make sptps_receive_data_datagram() a little more readable.

The new code updates variables as stuff is being consumed, so that the
reader doesn't have to do that in his head.

Don't send local_address in ADD_EDGE messages if it's AF_UNSPEC.

Let sockaddr2hostname() handle AF_UNSPEC addresses.

Prevent SPTPS key regeneration packets from entering an UDP relay path.

Commit 10c1f60c643607d9dafd79271c3475cddf81e903 introduced a mechanism
by which a packet received by REQ_KEY could continue its journey over
UDP. This was based on the assumption that REQ_KEY messages would never
be used for handshake packets (which should never be sent over UDP,
because SPTPS currently doesn't handle lost handshake packets very
well).

Unfortunately, there is one case where handshake packets are sent using
REQ_KEY: when regenerating the SPTPS key for a pre-established channel.
With the current code, such packets risk getting relayed over UDP.

When processing a REQ_KEY message, it is impossible for the receiving
end to distinguish between a data SPTPS packet and a handshake packet,
because this information is stored in the type field which is encrypted
with the end-to-end key.

This commit fixes the issue by making tinc use ANS_KEY for all SPTPS
handshake messages. This works because ANS_KEY messages are never
forwarded using the SPTPS relay mechanisms, therefore they are
guaranteed to stick to TCP.

Let sockaddr2str() handle AF_UNSPEC addresses.

Try all addresses for the hostname in an invitation URL.

Be more liberal accepting ADD_EDGE messages with conflicting local address information.

If the ADD_EDGE is for one of the edges we own, and if it is not the
same as we actually have, send a correcting ADD_EDGE back. Otherwise, if
the ADD_EDGE contains new information, update our idea of the local
address for that edge.

If the ADD_EDGE does not contain local address information, then we
never make a correction nor log a warning.

Use AF_UNSPEC instead of AF_UNKNOWN for unspecified local address in add_edge_h().

AF_UNKNOWN is reserved for valid addresses that the local node cannot
parse, but remote nodes possibly can.

Fix receiving UDP packets from tinc 1.0.x nodes.

In try_mac(), the wrong offsets were used into the packet buffer,
causing the digest verification to always fail.

Fix invitations.

These were broken due to a change in behaviour of sptps_receive_data()
introduced in commit d237efd325cd7bdd73f5eb111c769470238dce6e.