This means: setup_outgoing_connection() has to prepare fake
Address = "ip port" config based on the actuall configuration file
Prefer the addresses discovered via SLDP while making outgoing connections
After first tests it came out, that RoadWarriors with multiple
active Interfaces hat problems with receiving on/ and sending SLPD
packets to specific interfaces.
Here the solution:
- Define SLPDInterface in your tinc.conf (multiple definitions are allowed)
On those interfaces tincd will send and receive SLPD packetes
- You have to have IPv6 support on - link-local addresses configured
- tincd must listen on IPv6 on your SLPDInterfaces
- Define SLPDGroup to something like ff02::42:1
- Define SLPDPort for your group
- Define SLPDInterval to some sane number of seconds (0 is default,
meaning SLPD is disabled, 30 seconds should be enough for average
users)
SLPDGroup and SLPDPort should be unique for your network.
Fingerprinting, message signing is yet to be implemented.
Discovered address should also expire periodically.
Full functionality of tinc mesh relays on having at least one node,
accessible, with known address to which all other nodes must connect
in order to exchange information about other peers.
Sometimes, however, in smaller networks or if two or more peers are
located in the same LAN segment without access to any of the nodes with
known address, there is no way of establishing a functional mesh
without manually changing the configuration.
SLPD addresses this problem utilizing multicast groups and autoconnect.
- Node sends periodically simple message to multicast group
(default 224.0.42.23 port 1655) in this format:
"sLPD 0 1 nodename port publickey"
"0 1" is the "major minior" version of the protocol
- Node listens to the multicast group for messages on all interfaces:
- if the nodename is known and the publickey matches the
node's public key the source address of the packet
will be stored as learned ip address
- at this point setup_outgoing_connection() will be able to
choose the learned ip for connect
Configarion example:
* Roadwarriors: SLPDInterval = 30
* Router on your home network or in your hackerspace:
- It should broadcast only in the direction of the LAN thus you should
set SLPDInterface = eth0 and SLPDInterval = 10
* Defaults:
SLPDGroup = "224.0.42.23"
SLPDPort = 1655
SLPDInterval = 0 (means SLPD is disabled)
The check of the publickey is not implemented yet. IPv6 support
must be implemented. This is the first commit - highly experimental.
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
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.
This problem occurs on "road-warriors" when tincd setups
outgoing connections but you do not have any active uplink then
dns-lookups will fail and any following attempt to make outgoing
connections will keep failing forever.
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
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.
Average RTT can be used to update edge weight and propagate it to the network.
tinc dump edges has been also extended to give the current RTT.
New edge weight will change only if the config has EdgeUpdateInterval set to other value than 0.
- Ignore local configuration for editors
- Extended manpage with informations about EdgeUpdateInterval
- Added clone_edge and fixed potential segfault when b->from not defined
- Compute avg_rtt based on the time values we got back in PONG
- Add avg_rtt on dump edge
- Send current time on PING and return it on PONG
- Changed last_ping_time to struct timeval
- Extended edge_t with avg_rtt
It may not be obvious, but due to the way tinc operates (single-threaded
control loop with no intermediate packet buffer), UDP send and receive
buffers can have a massive impact on performance. It is therefore of
paramount importance that the buffers be large enough to prevent packet
drops that could occur while tinc is processing a packet.
Leaving that value to the OS default could be reasonable if we weren't
relying on it so much. Instead, this makes performance somewhat
unpredictable.
In practice, the worst case scenario occurs on Windows, where Microsoft
had the brillant idea of making the buffers 8K in size by default, no
matter what the link speed is. Considering that 8K flies past in a
matter of microseconds on >1G links, this is extremely inappropriate. On
these systems, changing the buffer size to 1M results in *obscene*
raw throughput improvements; I have observed a 10X jump from 40 Mbit/s
to 400 Mbit/s on my system.
In this commit, we stop trusting the OS to get this right and we use a
fixed 1M value instead, which should be enough for <=1G links.
The option "--disable-legacy-protocol" was added to the configure
script. The new protocol does not depend on any external crypto
libraries, so when the option is used tinc is no longer linked to
OpenSSL's libcrypto.
The only places where connection_t::status.active is modified is in
ack_h() and terminate_connection(). In both cases, connection_t::edge
is added and removed at the same time, and that's the only places
connection_t::edge is set. Therefore, the following is true at all
times:
!c->status.active == !c->edge
This commit removes the redundant state information by getting rid of
connection_t::status.active, and using connection_t::edge instead.
Commit 86a99c6b99 changed the way we
handle connection events to protect against spurious event loop
callbacks. Unfortunately, it turns out that calling connect() twice on
the same socket results in different behaviors depending on the platform
(even though it seems well defined in POSIX). On Windows this resulted
in the connection handling code being unable to react to connection
errors (such as connection refused), always hitting the timeout; on
Linux this resulted in spurious error messages about connect() returning
success.
In POSIX and on Linux, using connect() on a socket where the previous
attempt failed will attempt to connect again, resulting in unnecessary
network activity. Using getsockopt(SO_ERROR) before connect() solves
that, but introduces a race condition if a connection failure happens
between the two calls.
For this reason, this commit switches from connect() to a zero-sized
send() call, which is more consistent (though not completely, see the
truth table in the comments) and simpler to use for that purpose. Note
that Windows explictly support empty send() calls; POSIX says nothing
on the subject, but testing shows it works at least on Linux.
(Surprisingly enough, Windows seems more POSIX-compliant than Linux on
this one!)
The event loop does not guarantee that spurious write I/O events do not
happen; in fact, they are guaranteed to happen on Windows when
event_flush_output() is called. Because handle_meta_io() does not check
for spurious events, a metaconnection socket might appear connected even
though it's not, and will fail immediately when sending the ID request.
This commit fixes this issue by making handle_meta_io() check the
connection status before assuming the socket is connected. It seems that
the only reliable way to do that is to try to call connect() again and
look at the error code, which will be EISCONN if the socket is
connected, or EALREADY if it's not.
When using socket functions, "sockerrno" is supposed to be used to
retrieve the error code as opposed to "errno", so that it is translated
to the correct call on Windows (WSAGetLastError() - Windows does not
update errno on socket errors). Unfortunately, the use of sockerrno is
inconsistent throughout the tinc codebase, as errno is often used
incorrectly on socket-related calls.
This commit fixes these oversights, which improves socket error
handling on Windows.
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.
ListenAddress works the same as BindToAddress, except that from now on,
explicitly binding outgoing packets to the address of a socket is only done for
sockets specified with BindToAddress.
The restriction of accepting only 1 connection per second from a single address
is a bit too much, especially if one wants to join a VPN using an invitation,
which requires two connections.
Commit cff5a84 removed the feature of binding outgoing TCP sockets to a local
address. We now call bind() again, but only if there is exactly one listening
socket with the same address family as the destination address of the outgoing
socket.
Tinc now strictly limits incoming connections from the same host to 1 per
second. For incoming connections from multiple hosts short bursts of incoming
connections are allowed (by default 100), but on average also only 1 connection
per second is allowed.
When an incoming connection exceeds the limit, tinc will keep the connection in
a tarpit; the connection will be kept open but it is ignored completely. Only
one connection is in a tarpit at a time to limit the number of useless open
connections.
