2002-02-18 16:25:19 +00:00
/*
net_packet . c - - Handles in - and outgoing VPN packets
2006-04-26 13:52:58 +00:00
Copyright ( C ) 1998 - 2005 Ivo Timmermans ,
2014-12-24 21:15:40 +00:00
2000 - 2014 Guus Sliepen < guus @ tinc - vpn . org >
2010-10-22 11:40:04 +00:00
2010 Timothy Redaelli < timothy @ redaelli . eu >
2010-11-16 16:28:41 +00:00
2010 Brandon Black < blblack @ gmail . com >
2002-02-18 16:25:19 +00:00
This program is free software ; you can redistribute it and / or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation ; either version 2 of the License , or
( at your option ) any later version .
This program is distributed in the hope that it will be useful ,
but WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
GNU General Public License for more details .
2009-09-24 22:01:00 +00:00
You should have received a copy of the GNU General Public License along
with this program ; if not , write to the Free Software Foundation , Inc . ,
51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA .
2002-02-18 16:25:19 +00:00
*/
2003-07-17 15:06:27 +00:00
# include "system.h"
2002-02-18 16:25:19 +00:00
2010-02-10 13:52:15 +00:00
# ifdef HAVE_ZLIB
2002-02-18 16:25:19 +00:00
# include <zlib.h>
2010-02-10 13:52:15 +00:00
# endif
2010-02-10 12:24:33 +00:00
# ifdef HAVE_LZO
2006-11-29 17:18:39 +00:00
# include LZO1X_H
2010-02-10 12:24:33 +00:00
# endif
2002-02-18 16:25:19 +00:00
2008-12-11 14:44:44 +00:00
# include "cipher.h"
2002-02-18 16:25:19 +00:00
# include "conf.h"
# include "connection.h"
2008-12-11 14:44:44 +00:00
# include "crypto.h"
# include "digest.h"
2003-07-17 15:06:27 +00:00
# include "device.h"
2003-12-27 16:32:52 +00:00
# include "ethernet.h"
2014-12-31 16:12:11 +00:00
# include "ipv4.h"
# include "ipv6.h"
2003-07-17 15:06:27 +00:00
# include "graph.h"
# include "logger.h"
2002-02-18 16:25:19 +00:00
# include "net.h"
# include "netutl.h"
# include "protocol.h"
# include "route.h"
2003-07-17 15:06:27 +00:00
# include "utils.h"
# include "xalloc.h"
2002-02-18 16:25:19 +00:00
2014-10-12 18:44:33 +00:00
# ifndef MAX
# define MAX(a, b) ((a) > (b) ? (a) : (b))
# endif
2015-01-11 12:53:16 +00:00
/* The minimum size of a probe is 14 bytes, but since we normally use CBC mode
encryption , we can add a few extra random bytes without increasing the
resulting packet size . */
# define MIN_PROBE_SIZE 18
2002-02-18 16:25:19 +00:00
int keylifetime = 0 ;
2015-04-11 13:27:28 +00:00
int edgeupdateinterval = 0 ;
2010-02-10 12:24:33 +00:00
# ifdef HAVE_LZO
2003-07-06 23:16:29 +00:00
static char lzo_wrkmem [ LZO1X_999_MEM_COMPRESS > LZO1X_1_MEM_COMPRESS ? LZO1X_999_MEM_COMPRESS : LZO1X_1_MEM_COMPRESS ] ;
2010-02-10 12:24:33 +00:00
# endif
2003-05-06 21:13:18 +00:00
2003-12-20 19:47:53 +00:00
static void send_udppacket ( node_t * , vpn_packet_t * ) ;
2002-02-18 16:25:19 +00:00
2015-03-15 18:01:03 +00:00
unsigned replaywin = 32 ;
2014-06-29 10:06:44 +00:00
bool localdiscovery = true ;
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
bool udp_discovery = true ;
2015-01-11 16:44:50 +00:00
int udp_discovery_keepalive_interval = 10 ;
2015-01-03 10:05:57 +00:00
int udp_discovery_interval = 2 ;
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
int udp_discovery_timeout = 30 ;
2010-11-13 18:05:50 +00:00
2002-02-18 16:25:19 +00:00
# define MAX_SEQNO 1073741824
2015-01-01 10:32:14 +00:00
static void try_fix_mtu ( node_t * n ) {
2015-01-01 16:04:08 +00:00
if ( n - > mtuprobes < 0 )
2015-01-01 10:32:14 +00:00
return ;
2014-12-30 17:02:38 +00:00
if ( n - > mtuprobes = = 20 | | n - > minmtu > = n - > maxmtu ) {
2015-01-01 10:32:14 +00:00
if ( n - > minmtu > n - > maxmtu )
n - > minmtu = n - > maxmtu ;
else
n - > maxmtu = n - > minmtu ;
n - > mtu = n - > minmtu ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " Fixing MTU of %s (%s) to %d after %d probes " , n - > name , n - > hostname , n - > mtu , n - > mtuprobes ) ;
2015-01-01 16:04:08 +00:00
n - > mtuprobes = - 1 ;
2015-01-01 10:32:14 +00:00
}
}
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
static void udp_probe_timeout_handler ( void * data ) {
node_t * n = data ;
if ( ! n - > status . udp_confirmed )
return ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " Too much time has elapsed since last UDP ping response from %s (%s), stopping UDP communication " , n - > name , n - > hostname ) ;
n - > status . udp_confirmed = false ;
2015-01-11 15:10:58 +00:00
n - > maxrecentlen = 0 ;
Remove PMTU discovery code redundant with UDP discovery.
This is a rewrite of the send_mtu_probe_handler() function to make it
focus on the actual discovery of PMTU. In particular, the PMTU
discovery code doesn't care about tunnel state anymore - it only cares
about doing the initial PMTU discovery, and once that's done, making
sure PMTU did not increase by checking it from time to time. All other
duties have already been rewritten in the UDP discovery code.
As a result, the send_mtu_probe_handler(), which previously implemented
a nightmarish state machine which was very difficult to follow and
understand, has been massively simplified. We moved from four persistent
states to only two - initial discovery and steady state.
Furthermore, a side effect is that network chatter is reduced: instead
of sending bursts of three minmtu-sized packets in the steady state,
there is only one such packet that's sent from the UDP discovery code.
However, that introduces a slight regression in the bandwidth estimation
code, which relies on three-packet bursts in order to function.
Considering that this estimation is extremely unreliable (in my
experience) and isn't relied on by anything, this seems like an
acceptable regression.
2014-12-29 16:11:04 +00:00
n - > mtuprobes = 0 ;
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
n - > minmtu = 0 ;
n - > maxmtu = MTU ;
}
2015-01-11 15:12:57 +00:00
static void send_udp_probe_reply ( node_t * n , vpn_packet_t * packet , length_t len ) {
if ( ! n - > status . sptps & & ! n - > status . validkey ) {
2015-01-11 16:44:50 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Trying to send UDP probe reply to %s (%s) but we don't have his key yet " , n - > name , n - > hostname ) ;
2015-01-11 15:12:57 +00:00
return ;
}
/* Type 2 probe replies were introduced in protocol 17.3 */
if ( ( n - > options > > 24 ) > = 3 ) {
2015-01-11 16:44:50 +00:00
DATA ( packet ) [ 0 ] = 2 ;
uint16_t len16 = htons ( len ) ;
memcpy ( DATA ( packet ) + 1 , & len16 , 2 ) ;
2015-01-11 15:12:57 +00:00
packet - > len = MIN_PROBE_SIZE ;
2015-01-11 16:44:50 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending type 2 probe reply length %u to %s (%s) " , len , n - > name , n - > hostname ) ;
2015-01-11 15:12:57 +00:00
} else {
/* Legacy protocol: n won't understand type 2 probe replies. */
DATA ( packet ) [ 0 ] = 1 ;
2015-01-11 16:44:50 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending type 1 probe reply length %u to %s (%s) " , len , n - > name , n - > hostname ) ;
2015-01-11 15:12:57 +00:00
}
/* Temporarily set udp_confirmed, so that the reply is sent
back exactly the way it came in . */
bool udp_confirmed = n - > status . udp_confirmed ;
n - > status . udp_confirmed = true ;
send_udppacket ( n , packet ) ;
n - > status . udp_confirmed = udp_confirmed ;
}
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
static void udp_probe_h ( node_t * n , vpn_packet_t * packet , length_t len ) {
2014-12-24 21:23:24 +00:00
if ( ! DATA ( packet ) [ 0 ] ) {
2015-01-11 16:44:50 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Got UDP probe request %d from %s (%s) " , packet - > len , n - > name , n - > hostname ) ;
2015-01-11 15:12:57 +00:00
return send_udp_probe_reply ( n , packet , len ) ;
}
2012-11-19 13:20:50 +00:00
2015-01-11 15:12:57 +00:00
if ( DATA ( packet ) [ 0 ] = = 2 ) {
// It's a type 2 probe reply, use the length field inside the packet
uint16_t len16 ;
memcpy ( & len16 , DATA ( packet ) + 1 , 2 ) ;
len = ntohs ( len16 ) ;
}
logger ( DEBUG_TRAFFIC , LOG_INFO , " Got type %d UDP probe reply %d from %s (%s) " , DATA ( packet ) [ 0 ] , len , n - > name , n - > hostname ) ;
/* It's a valid reply: now we know bidirectional communication
is possible using the address and socket that the reply
packet used . */
n - > status . udp_confirmed = true ;
2015-01-11 16:44:50 +00:00
// Reset the UDP ping timer.
n - > udp_ping_sent = now ;
2015-01-11 15:12:57 +00:00
if ( udp_discovery ) {
timeout_del ( & n - > udp_ping_timeout ) ;
timeout_add ( & n - > udp_ping_timeout , & udp_probe_timeout_handler , n , & ( struct timeval ) { udp_discovery_timeout , 0 } ) ;
}
if ( len > n - > maxmtu ) {
logger ( DEBUG_TRAFFIC , LOG_INFO , " Increase in PMTU to %s (%s) detected, restarting PMTU discovery " , n - > name , n - > hostname ) ;
n - > minmtu = len ;
n - > maxmtu = MTU ;
/* Set mtuprobes to 1 so that try_mtu() doesn't reset maxmtu */
n - > mtuprobes = 1 ;
return ;
} else if ( n - > mtuprobes < 0 & & len = = n - > maxmtu ) {
/* We got a maxmtu sized packet, confirming the PMTU is still valid. */
n - > mtuprobes = - 1 ;
n - > mtu_ping_sent = now ;
}
/* If applicable, raise the minimum supported MTU */
if ( n - > minmtu < len ) {
n - > minmtu = len ;
try_fix_mtu ( n ) ;
2003-12-20 19:47:53 +00:00
}
}
2007-05-18 10:00:00 +00:00
static length_t compress_packet ( uint8_t * dest , const uint8_t * source , length_t len , int level ) {
2010-02-10 13:52:15 +00:00
if ( level = = 0 ) {
memcpy ( dest , source , len ) ;
return len ;
} else if ( level = = 10 ) {
2010-02-10 12:24:33 +00:00
# ifdef HAVE_LZO
2003-05-07 11:21:58 +00:00
lzo_uint lzolen = MAXSIZE ;
2003-05-06 21:13:18 +00:00
lzo1x_1_compress ( source , len , dest , & lzolen , lzo_wrkmem ) ;
return lzolen ;
2010-02-10 12:24:33 +00:00
# else
return - 1 ;
# endif
2003-05-06 21:13:18 +00:00
} else if ( level < 10 ) {
2010-02-10 13:52:15 +00:00
# ifdef HAVE_ZLIB
2003-05-06 23:14:45 +00:00
unsigned long destlen = MAXSIZE ;
2003-05-06 21:13:18 +00:00
if ( compress2 ( dest , & destlen , source , len , level ) = = Z_OK )
return destlen ;
else
2010-02-10 13:52:15 +00:00
# endif
2003-05-06 21:13:18 +00:00
return - 1 ;
} else {
2010-02-10 12:24:33 +00:00
# ifdef HAVE_LZO
2003-05-07 11:21:58 +00:00
lzo_uint lzolen = MAXSIZE ;
2003-05-06 21:13:18 +00:00
lzo1x_999_compress ( source , len , dest , & lzolen , lzo_wrkmem ) ;
return lzolen ;
2010-02-10 12:24:33 +00:00
# else
return - 1 ;
# endif
2003-05-06 21:13:18 +00:00
}
2012-10-10 15:17:49 +00:00
2003-05-06 21:13:18 +00:00
return - 1 ;
}
2007-05-18 10:00:00 +00:00
static length_t uncompress_packet ( uint8_t * dest , const uint8_t * source , length_t len , int level ) {
2010-02-10 13:52:15 +00:00
if ( level = = 0 ) {
memcpy ( dest , source , len ) ;
return len ;
} else if ( level > 9 ) {
2010-02-10 12:24:33 +00:00
# ifdef HAVE_LZO
2003-05-07 11:21:58 +00:00
lzo_uint lzolen = MAXSIZE ;
2003-05-06 21:13:18 +00:00
if ( lzo1x_decompress_safe ( source , len , dest , & lzolen , NULL ) = = LZO_E_OK )
return lzolen ;
else
2010-02-10 12:24:33 +00:00
# endif
2003-05-06 21:13:18 +00:00
return - 1 ;
2010-02-10 13:52:15 +00:00
}
# ifdef HAVE_ZLIB
else {
2003-05-06 23:14:45 +00:00
unsigned long destlen = MAXSIZE ;
2003-05-06 21:13:18 +00:00
if ( uncompress ( dest , & destlen , source , len ) = = Z_OK )
return destlen ;
else
return - 1 ;
}
2010-02-10 13:52:15 +00:00
# endif
2003-05-06 21:13:18 +00:00
return - 1 ;
}
2002-02-18 16:25:19 +00:00
/* VPN packet I/O */
2007-05-18 10:00:00 +00:00
static void receive_packet ( node_t * n , vpn_packet_t * packet ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Received packet of %d bytes from %s (%s) " ,
2003-07-06 23:16:29 +00:00
packet - > len , n - > name , n - > hostname ) ;
2011-05-14 22:42:29 +00:00
n - > in_packets + + ;
n - > in_bytes + = packet - > len ;
2003-12-12 19:52:25 +00:00
route ( n , packet ) ;
2003-07-06 23:16:29 +00:00
}
2009-09-29 12:55:29 +00:00
static bool try_mac ( node_t * n , const vpn_packet_t * inpkt ) {
2012-07-31 19:43:49 +00:00
if ( n - > status . sptps )
2014-12-24 21:23:24 +00:00
return sptps_verify_datagram ( & n - > sptps , DATA ( inpkt ) , inpkt - > len ) ;
2012-07-31 18:36:35 +00:00
2014-12-29 21:57:18 +00:00
# ifdef DISABLE_LEGACY
return false ;
# else
2015-01-12 13:43:32 +00:00
if ( ! n - > status . validkey_in | | ! digest_active ( n - > indigest ) | | inpkt - > len < sizeof ( seqno_t ) + digest_length ( n - > indigest ) )
2009-04-02 23:05:23 +00:00
return false ;
2015-03-18 13:54:45 +00:00
return digest_verify ( n - > indigest , ( inpkt ) - > data + ( inpkt ) - > offset , inpkt - > len - digest_length ( n - > indigest ) , DATA ( inpkt ) + inpkt - > len - digest_length ( n - > indigest ) ) ;
2014-12-29 21:57:18 +00:00
# endif
2009-04-02 23:05:23 +00:00
}
2014-09-27 17:13:33 +00:00
static bool receive_udppacket ( node_t * n , vpn_packet_t * inpkt ) {
2002-09-09 21:25:28 +00:00
vpn_packet_t pkt1 , pkt2 ;
vpn_packet_t * pkt [ ] = { & pkt1 , & pkt2 , & pkt1 , & pkt2 } ;
int nextpkt = 0 ;
2008-12-11 14:44:44 +00:00
size_t outlen ;
2014-12-24 21:23:24 +00:00
pkt1 . offset = DEFAULT_PACKET_OFFSET ;
pkt2 . offset = DEFAULT_PACKET_OFFSET ;
2002-09-09 21:25:28 +00:00
2012-07-31 19:43:49 +00:00
if ( n - > status . sptps ) {
2013-05-18 14:11:30 +00:00
if ( ! n - > sptps . state ) {
if ( ! n - > status . waitingforkey ) {
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Got packet from %s (%s) but we haven't exchanged keys yet " , n - > name , n - > hostname ) ;
send_req_key ( n ) ;
} else {
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Got packet from %s (%s) but he hasn't got our key yet " , n - > name , n - > hostname ) ;
}
2014-09-27 17:13:33 +00:00
return false ;
2013-05-18 14:11:30 +00:00
}
2015-01-11 16:44:50 +00:00
n - > status . udppacket = true ;
2015-05-18 19:48:45 +00:00
bool result = sptps_receive_data ( & n - > sptps , DATA ( inpkt ) , inpkt - > len ) ;
2015-01-11 16:44:50 +00:00
n - > status . udppacket = false ;
if ( ! result ) {
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.
2015-05-17 17:50:11 +00:00
/* Uh-oh. It might be that the tunnel is stuck in some corrupted state,
so let ' s restart SPTPS in case that helps . But don ' t do that too often
to prevent storms , and because that would make life a little too easy
for external attackers trying to DoS us . */
if ( n - > last_req_key < now . tv_sec - 10 ) {
logger ( DEBUG_PROTOCOL , LOG_ERR , " Failed to decode raw TCP packet from %s (%s), restarting SPTPS " , n - > name , n - > hostname ) ;
send_req_key ( n ) ;
}
2014-12-07 16:25:30 +00:00
return false ;
}
return true ;
2012-07-30 16:36:59 +00:00
}
2014-12-29 21:57:18 +00:00
# ifdef DISABLE_LEGACY
return false ;
# else
2015-01-10 21:26:33 +00:00
if ( ! n - > status . validkey_in ) {
2013-05-18 14:11:30 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Got packet from %s (%s) but he hasn't got our key yet " , n - > name , n - > hostname ) ;
2014-09-27 17:13:33 +00:00
return false ;
2009-04-02 23:05:23 +00:00
}
2004-03-20 22:23:42 +00:00
/* Check packet length */
2014-12-24 21:23:24 +00:00
if ( inpkt - > len < sizeof ( seqno_t ) + digest_length ( n - > indigest ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Got too short packet from %s (%s) " ,
2004-03-20 22:23:42 +00:00
n - > name , n - > hostname ) ;
2014-09-27 17:13:33 +00:00
return false ;
2003-09-23 20:59:01 +00:00
}
2014-12-24 21:23:24 +00:00
/* It's a legacy UDP packet, the data starts after the seqno */
inpkt - > offset + = sizeof ( seqno_t ) ;
2004-03-20 22:23:42 +00:00
/* Check the message authentication code */
2013-05-01 15:17:22 +00:00
if ( digest_active ( n - > indigest ) ) {
inpkt - > len - = digest_length ( n - > indigest ) ;
2014-12-24 21:23:24 +00:00
if ( ! digest_verify ( n - > indigest , SEQNO ( inpkt ) , inpkt - > len , SEQNO ( inpkt ) + inpkt - > len ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Got unauthenticated packet from %s (%s) " , n - > name , n - > hostname ) ;
2014-09-27 17:13:33 +00:00
return false ;
2009-12-18 00:15:25 +00:00
}
2004-03-20 22:23:42 +00:00
}
2002-09-09 21:25:28 +00:00
/* Decrypt the packet */
2013-05-01 15:17:22 +00:00
if ( cipher_active ( n - > incipher ) ) {
2014-07-12 10:13:04 +00:00
vpn_packet_t * outpkt = pkt [ nextpkt + + ] ;
2008-12-11 14:44:44 +00:00
outlen = MAXSIZE ;
2002-09-09 21:25:28 +00:00
2014-12-24 21:23:24 +00:00
if ( ! cipher_decrypt ( n - > incipher , SEQNO ( inpkt ) , inpkt - > len , SEQNO ( outpkt ) , & outlen , true ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Error decrypting packet from %s (%s) " , n - > name , n - > hostname ) ;
2014-09-27 17:13:33 +00:00
return false ;
2003-10-10 16:24:24 +00:00
}
2012-10-10 15:17:49 +00:00
2008-12-11 14:44:44 +00:00
outpkt - > len = outlen ;
2002-09-09 21:25:28 +00:00
inpkt = outpkt ;
}
/* Check the sequence number */
2014-12-24 21:23:24 +00:00
seqno_t seqno ;
memcpy ( & seqno , SEQNO ( inpkt ) , sizeof seqno ) ;
seqno = ntohl ( seqno ) ;
inpkt - > len - = sizeof seqno ;
2002-09-09 21:25:28 +00:00
2010-11-13 18:05:50 +00:00
if ( replaywin ) {
2014-09-27 12:34:56 +00:00
if ( seqno ! = n - > received_seqno + 1 ) {
if ( seqno > = n - > received_seqno + replaywin * 8 ) {
2010-11-13 18:05:51 +00:00
if ( n - > farfuture + + < replaywin > > 2 ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_ALWAYS , LOG_WARNING , " Packet from %s (%s) is %d seqs in the future, dropped (%u) " ,
2014-09-27 12:34:56 +00:00
n - > name , n - > hostname , seqno - n - > received_seqno - 1 , n - > farfuture ) ;
2014-09-27 17:13:33 +00:00
return false ;
2010-11-13 18:05:51 +00:00
}
2012-02-26 17:37:36 +00:00
logger ( DEBUG_ALWAYS , LOG_WARNING , " Lost %d packets from %s (%s) " ,
2014-09-27 12:34:56 +00:00
seqno - n - > received_seqno - 1 , n - > name , n - > hostname ) ;
2010-11-13 18:05:50 +00:00
memset ( n - > late , 0 , replaywin ) ;
2014-09-27 12:34:56 +00:00
} else if ( seqno < = n - > received_seqno ) {
if ( ( n - > received_seqno > = replaywin * 8 & & seqno < = n - > received_seqno - replaywin * 8 ) | | ! ( n - > late [ ( seqno / 8 ) % replaywin ] & ( 1 < < seqno % 8 ) ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_ALWAYS , LOG_WARNING , " Got late or replayed packet from %s (%s), seqno %d, last received %d " ,
2014-09-27 12:34:56 +00:00
n - > name , n - > hostname , seqno , n - > received_seqno ) ;
2014-09-27 17:13:33 +00:00
return false ;
2010-11-13 18:05:50 +00:00
}
} else {
2014-09-27 12:34:56 +00:00
for ( int i = n - > received_seqno + 1 ; i < seqno ; i + + )
2010-11-13 18:05:50 +00:00
n - > late [ ( i / 8 ) % replaywin ] | = 1 < < i % 8 ;
2004-09-20 20:55:49 +00:00
}
2003-04-18 21:18:36 +00:00
}
2010-11-13 18:05:51 +00:00
n - > farfuture = 0 ;
2014-09-27 12:34:56 +00:00
n - > late [ ( seqno / 8 ) % replaywin ] & = ~ ( 1 < < seqno % 8 ) ;
2002-09-09 21:25:28 +00:00
}
2004-11-08 22:30:13 +00:00
2014-09-27 12:34:56 +00:00
if ( seqno > n - > received_seqno )
n - > received_seqno = seqno ;
2012-10-10 15:17:49 +00:00
2013-01-15 12:33:16 +00:00
n - > received + + ;
2002-09-09 21:25:28 +00:00
if ( n - > received_seqno > MAX_SEQNO )
2007-05-17 23:57:48 +00:00
regenerate_key ( ) ;
2002-09-09 21:25:28 +00:00
/* Decompress the packet */
2009-05-25 10:19:37 +00:00
length_t origlen = inpkt - > len ;
2009-04-02 23:05:23 +00:00
if ( n - > incompression ) {
2014-07-12 10:13:04 +00:00
vpn_packet_t * outpkt = pkt [ nextpkt + + ] ;
2002-09-09 21:25:28 +00:00
2014-12-24 21:23:24 +00:00
if ( ( outpkt - > len = uncompress_packet ( DATA ( outpkt ) , DATA ( inpkt ) , inpkt - > len , n - > incompression ) ) < 0 ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_ERR , " Error while uncompressing packet from %s (%s) " ,
2012-10-10 15:17:49 +00:00
n - > name , n - > hostname ) ;
2014-09-27 17:13:33 +00:00
return false ;
2002-09-09 21:25:28 +00:00
}
inpkt = outpkt ;
2009-05-25 10:19:37 +00:00
origlen - = MTU / 64 + 20 ;
2002-09-09 21:25:28 +00:00
}
2015-01-11 15:10:58 +00:00
if ( inpkt - > len > n - > maxrecentlen )
n - > maxrecentlen = inpkt - > len ;
2009-01-03 21:33:55 +00:00
inpkt - > priority = 0 ;
2014-12-24 21:23:24 +00:00
if ( ! DATA ( inpkt ) [ 12 ] & & ! DATA ( inpkt ) [ 13 ] )
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
udp_probe_h ( n , inpkt , origlen ) ;
2003-12-20 19:47:53 +00:00
else
receive_packet ( n , inpkt ) ;
2014-09-27 17:13:33 +00:00
return true ;
2014-12-29 21:57:18 +00:00
# endif
2002-02-18 16:25:19 +00:00
}
2011-05-28 21:36:52 +00:00
void receive_tcppacket ( connection_t * c , const char * buffer , int len ) {
2002-09-09 21:25:28 +00:00
vpn_packet_t outpkt ;
2014-12-24 21:23:24 +00:00
outpkt . offset = DEFAULT_PACKET_OFFSET ;
2002-09-09 21:25:28 +00:00
2014-12-24 21:23:24 +00:00
if ( len > sizeof outpkt . data - outpkt . offset )
2013-04-12 15:15:05 +00:00
return ;
2002-09-09 21:25:28 +00:00
outpkt . len = len ;
2009-01-03 21:33:55 +00:00
if ( c - > options & OPTION_TCPONLY )
outpkt . priority = 0 ;
else
outpkt . priority = - 1 ;
2014-12-24 21:23:24 +00:00
memcpy ( DATA ( & outpkt ) , buffer , len ) ;
2002-09-09 21:25:28 +00:00
receive_packet ( c - > node , & outpkt ) ;
2002-02-18 16:25:19 +00:00
}
Introduce raw TCP SPTPS packet transport.
Currently, SPTPS packets are transported over TCP metaconnections using
extended REQ_KEY requests, in order for the packets to pass through
tinc-1.0 nodes unaltered. Unfortunately, this method presents two
significant downsides:
- An already encrypted SPTPS packet is decrypted and then encrypted
again every time it passes through a node, since it is transported
over the SPTPS channels of the metaconnections. This
double-encryption is unnecessary and wastes CPU cycles.
- More importantly, the only way to transport binary data over
standard metaconnection messages such as REQ_KEY is to encode it
in base64, which has a 33% encoding overhead. This wastes 25% of the
network bandwidth.
This commit introduces a new protocol message, SPTPS_PACKET, which can
be used to transport SPTPS packets over a TCP metaconnection in an
efficient way. The new message is appropriately protected through a
minor protocol version increment, and extended REQ_KEY messages are
still used with nodes that do not support the new message, as well as
for the intial handshake packets, for which efficiency is not a concern.
The way SPTPS_PACKET works is very similar to how the traditional PACKET
message works: after the SPTPS_PACKET message, the raw binary packet is
sent directly over the metaconnection. There is one important
difference, however: in the case of SPTPS_PACKET, the packet is sent
directly over the TCP stream completely bypassing the SPTPS channel of
the metaconnection itself for maximum efficiency. This is secure because
the SPTPS packet that is being sent is already encrypted with an
end-to-end key.
2015-05-10 18:00:03 +00:00
bool receive_tcppacket_sptps ( connection_t * c , const char * data , int len ) {
if ( len < sizeof ( node_id_t ) + sizeof ( node_id_t ) ) {
logger ( DEBUG_ALWAYS , LOG_ERR , " Got too short TCP SPTPS packet from %s (%s) " , c - > name , c - > hostname ) ;
return false ;
}
node_t * to = lookup_node_id ( ( node_id_t * ) data ) ;
data + = sizeof ( node_id_t ) ; len - = sizeof ( node_id_t ) ;
if ( ! to ) {
logger ( DEBUG_PROTOCOL , LOG_ERR , " Got TCP SPTPS packet from %s (%s) with unknown destination ID " , c - > name , c - > hostname ) ;
return true ;
}
node_t * from = lookup_node_id ( ( node_id_t * ) data ) ;
data + = sizeof ( node_id_t ) ; len - = sizeof ( node_id_t ) ;
if ( ! from ) {
logger ( DEBUG_PROTOCOL , LOG_ERR , " Got TCP SPTPS packet from %s (%s) with unknown source ID " , c - > name , c - > hostname ) ;
return true ;
}
/* Help the sender reach us over UDP.
Note that we only do this if we ' re the destination or the static relay ;
otherwise every hop would initiate its own UDP info message , resulting in elevated chatter . */
if ( to - > via = = myself )
send_udp_info ( myself , from ) ;
/* If we're not the final recipient, relay the packet. */
if ( to ! = myself ) {
send_sptps_data ( to , from , 0 , data , len ) ;
try_tx ( to , true ) ;
return true ;
}
/* The packet is for us */
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.
2015-05-17 17:50:11 +00:00
if ( ! sptps_receive_data ( & from - > sptps , data , len ) ) {
/* Uh-oh. It might be that the tunnel is stuck in some corrupted state,
so let ' s restart SPTPS in case that helps . But don ' t do that too often
to prevent storms . */
if ( from - > last_req_key < now . tv_sec - 10 ) {
logger ( DEBUG_PROTOCOL , LOG_ERR , " Failed to decode raw TCP packet from %s (%s), restarting SPTPS " , from - > name , from - > hostname ) ;
send_req_key ( from ) ;
}
Introduce raw TCP SPTPS packet transport.
Currently, SPTPS packets are transported over TCP metaconnections using
extended REQ_KEY requests, in order for the packets to pass through
tinc-1.0 nodes unaltered. Unfortunately, this method presents two
significant downsides:
- An already encrypted SPTPS packet is decrypted and then encrypted
again every time it passes through a node, since it is transported
over the SPTPS channels of the metaconnections. This
double-encryption is unnecessary and wastes CPU cycles.
- More importantly, the only way to transport binary data over
standard metaconnection messages such as REQ_KEY is to encode it
in base64, which has a 33% encoding overhead. This wastes 25% of the
network bandwidth.
This commit introduces a new protocol message, SPTPS_PACKET, which can
be used to transport SPTPS packets over a TCP metaconnection in an
efficient way. The new message is appropriately protected through a
minor protocol version increment, and extended REQ_KEY messages are
still used with nodes that do not support the new message, as well as
for the intial handshake packets, for which efficiency is not a concern.
The way SPTPS_PACKET works is very similar to how the traditional PACKET
message works: after the SPTPS_PACKET message, the raw binary packet is
sent directly over the metaconnection. There is one important
difference, however: in the case of SPTPS_PACKET, the packet is sent
directly over the TCP stream completely bypassing the SPTPS channel of
the metaconnection itself for maximum efficiency. This is secure because
the SPTPS packet that is being sent is already encrypted with an
end-to-end key.
2015-05-10 18:00:03 +00:00
return true ;
}
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.
2015-05-17 17:50:11 +00:00
Introduce raw TCP SPTPS packet transport.
Currently, SPTPS packets are transported over TCP metaconnections using
extended REQ_KEY requests, in order for the packets to pass through
tinc-1.0 nodes unaltered. Unfortunately, this method presents two
significant downsides:
- An already encrypted SPTPS packet is decrypted and then encrypted
again every time it passes through a node, since it is transported
over the SPTPS channels of the metaconnections. This
double-encryption is unnecessary and wastes CPU cycles.
- More importantly, the only way to transport binary data over
standard metaconnection messages such as REQ_KEY is to encode it
in base64, which has a 33% encoding overhead. This wastes 25% of the
network bandwidth.
This commit introduces a new protocol message, SPTPS_PACKET, which can
be used to transport SPTPS packets over a TCP metaconnection in an
efficient way. The new message is appropriately protected through a
minor protocol version increment, and extended REQ_KEY messages are
still used with nodes that do not support the new message, as well as
for the intial handshake packets, for which efficiency is not a concern.
The way SPTPS_PACKET works is very similar to how the traditional PACKET
message works: after the SPTPS_PACKET message, the raw binary packet is
sent directly over the metaconnection. There is one important
difference, however: in the case of SPTPS_PACKET, the packet is sent
directly over the TCP stream completely bypassing the SPTPS channel of
the metaconnection itself for maximum efficiency. This is secure because
the SPTPS packet that is being sent is already encrypted with an
end-to-end key.
2015-05-10 18:00:03 +00:00
send_mtu_info ( myself , from , MTU ) ;
return true ;
}
2012-08-02 15:44:59 +00:00
static void send_sptps_packet ( node_t * n , vpn_packet_t * origpkt ) {
2014-12-28 17:16:27 +00:00
if ( ! n - > status . validkey & & ! n - > connection )
2012-10-07 12:03:50 +00:00
return ;
2012-08-02 15:44:59 +00:00
2012-10-07 11:31:19 +00:00
uint8_t type = 0 ;
int offset = 0 ;
2012-08-02 15:44:59 +00:00
2014-12-24 21:23:24 +00:00
if ( ! ( DATA ( origpkt ) [ 12 ] | DATA ( origpkt ) [ 13 ] ) ) {
sptps_send_record ( & n - > sptps , PKT_PROBE , ( char * ) DATA ( origpkt ) , origpkt - > len ) ;
2012-10-07 11:31:19 +00:00
return ;
}
2012-08-02 15:44:59 +00:00
2012-10-07 11:31:19 +00:00
if ( routing_mode = = RMODE_ROUTER )
offset = 14 ;
else
type = PKT_MAC ;
2012-08-02 15:44:59 +00:00
2012-10-07 11:31:19 +00:00
if ( origpkt - > len < offset )
2012-08-02 15:44:59 +00:00
return ;
2012-10-07 11:31:19 +00:00
vpn_packet_t outpkt ;
if ( n - > outcompression ) {
2014-12-24 21:23:24 +00:00
outpkt . offset = 0 ;
int len = compress_packet ( DATA ( & outpkt ) + offset , DATA ( origpkt ) + offset , origpkt - > len - offset , n - > outcompression ) ;
2012-10-07 11:31:19 +00:00
if ( len < 0 ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " Error while compressing packet to %s (%s) " , n - > name , n - > hostname ) ;
} else if ( len < origpkt - > len - offset ) {
outpkt . len = len + offset ;
origpkt = & outpkt ;
type | = PKT_COMPRESSED ;
}
2012-08-02 15:44:59 +00:00
}
2012-10-07 11:31:19 +00:00
2014-10-12 11:14:46 +00:00
/* If we have a direct metaconnection to n, and we can't use UDP, then
don ' t bother with SPTPS and just use a " plaintext " PACKET message .
We don ' t really care about end - to - end security since we ' re not
sending the message through any intermediate nodes . */
if ( n - > connection & & origpkt - > len > n - > minmtu )
send_tcppacket ( n - > connection , origpkt ) ;
else
sptps_send_record ( & n - > sptps , type , DATA ( origpkt ) + offset , origpkt - > len - offset ) ;
2012-10-07 11:31:19 +00:00
return ;
2012-08-02 15:44:59 +00:00
}
2014-06-22 16:27:55 +00:00
static void adapt_socket ( const sockaddr_t * sa , int * sock ) {
/* Make sure we have a suitable socket for the chosen address */
if ( listen_socket [ * sock ] . sa . sa . sa_family ! = sa - > sa . sa_family ) {
for ( int i = 0 ; i < listen_sockets ; i + + ) {
if ( listen_socket [ i ] . sa . sa . sa_family = = sa - > sa . sa_family ) {
* sock = i ;
break ;
}
}
}
}
2012-11-17 21:48:06 +00:00
static void choose_udp_address ( const node_t * n , const sockaddr_t * * sa , int * sock ) {
/* Latest guess */
* sa = & n - > address ;
* sock = n - > sock ;
/* If the UDP address is confirmed, use it. */
if ( n - > status . udp_confirmed )
return ;
2012-11-19 12:50:17 +00:00
/* Send every third packet to n->address; that could be set
to the node ' s reflexive UDP address discovered during key
exchange . */
2012-11-17 21:48:06 +00:00
2012-11-19 12:50:17 +00:00
static int x = 0 ;
if ( + + x > = 3 ) {
x = 0 ;
return ;
}
/* Otherwise, address are found in edges to this node.
So we pick a random edge and a random socket . */
2012-11-17 21:48:06 +00:00
int i = 0 ;
int j = rand ( ) % n - > edge_tree - > count ;
edge_t * candidate = NULL ;
2012-11-19 12:50:17 +00:00
for splay_each ( edge_t , e , n - > edge_tree ) {
if ( i + + = = j ) {
candidate = e - > reverse ;
break ;
}
2012-11-17 21:48:06 +00:00
}
if ( candidate ) {
* sa = & candidate - > address ;
* sock = rand ( ) % listen_sockets ;
}
2014-06-22 16:27:55 +00:00
adapt_socket ( * sa , sock ) ;
}
static void choose_local_address ( const node_t * n , const sockaddr_t * * sa , int * sock ) {
2014-06-29 10:01:24 +00:00
* sa = NULL ;
2014-06-22 16:27:55 +00:00
/* Pick one of the edges from this node at random, then use its local address. */
int i = 0 ;
int j = rand ( ) % n - > edge_tree - > count ;
edge_t * candidate = NULL ;
for splay_each ( edge_t , e , n - > edge_tree ) {
if ( i + + = = j ) {
candidate = e ;
break ;
2012-11-17 21:48:06 +00:00
}
}
2014-06-22 16:27:55 +00:00
if ( candidate & & candidate - > local_address . sa . sa_family ) {
* sa = & candidate - > local_address ;
* sock = rand ( ) % listen_sockets ;
adapt_socket ( * sa , sock ) ;
2012-11-17 21:48:06 +00:00
}
}
2007-05-18 10:00:00 +00:00
static void send_udppacket ( node_t * n , vpn_packet_t * origpkt ) {
2002-09-09 21:25:28 +00:00
vpn_packet_t pkt1 , pkt2 ;
vpn_packet_t * pkt [ ] = { & pkt1 , & pkt2 , & pkt1 , & pkt2 } ;
2006-04-26 16:29:47 +00:00
vpn_packet_t * inpkt = origpkt ;
2002-09-09 21:25:28 +00:00
int nextpkt = 0 ;
vpn_packet_t * outpkt ;
2011-06-02 16:22:26 +00:00
int origlen = origpkt - > len ;
2008-12-11 14:44:44 +00:00
size_t outlen ;
2010-05-04 13:43:48 +00:00
# if defined(SOL_IP) && defined(IP_TOS)
2002-09-09 21:25:28 +00:00
static int priority = 0 ;
2012-07-21 10:51:53 +00:00
int origpriority = origpkt - > priority ;
2014-07-12 11:49:59 +00:00
# endif
2002-03-18 22:47:20 +00:00
2014-12-24 21:23:24 +00:00
pkt1 . offset = DEFAULT_PACKET_OFFSET ;
pkt2 . offset = DEFAULT_PACKET_OFFSET ;
2009-06-11 16:36:08 +00:00
if ( ! n - > status . reachable ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Trying to send UDP packet to unreachable node %s (%s) " , n - > name , n - > hostname ) ;
2009-06-11 16:36:08 +00:00
return ;
}
2012-08-02 15:44:59 +00:00
if ( n - > status . sptps )
return send_sptps_packet ( n , origpkt ) ;
2014-12-29 21:57:18 +00:00
# ifdef DISABLE_LEGACY
return ;
# else
2002-09-09 21:25:28 +00:00
/* Make sure we have a valid key */
2002-02-18 16:25:19 +00:00
2002-09-09 21:25:28 +00:00
if ( ! n - > status . validkey ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO ,
2009-09-24 22:54:07 +00:00
" No valid key known yet for %s (%s), forwarding via TCP " ,
2002-09-09 21:25:28 +00:00
n - > name , n - > hostname ) ;
2009-01-03 21:33:55 +00:00
send_tcppacket ( n - > nexthop - > connection , origpkt ) ;
2002-09-09 21:25:28 +00:00
return ;
}
2002-02-18 16:25:19 +00:00
2014-12-24 21:23:24 +00:00
if ( n - > options & OPTION_PMTU_DISCOVERY & & inpkt - > len > n - > minmtu & & ( DATA ( inpkt ) [ 12 ] | DATA ( inpkt ) [ 13 ] ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO ,
2009-10-24 19:53:01 +00:00
" Packet for %s (%s) larger than minimum MTU, forwarding via %s " ,
n - > name , n - > hostname , n ! = n - > nexthop ? n - > nexthop - > name : " TCP " ) ;
2009-01-03 21:33:55 +00:00
2009-10-24 19:53:01 +00:00
if ( n ! = n - > nexthop )
send_packet ( n - > nexthop , origpkt ) ;
else
send_tcppacket ( n - > nexthop - > connection , origpkt ) ;
2009-04-02 23:05:23 +00:00
return ;
2009-01-03 21:33:55 +00:00
}
2002-09-09 21:25:28 +00:00
/* Compress the packet */
2002-02-18 16:25:19 +00:00
2009-04-02 23:05:23 +00:00
if ( n - > outcompression ) {
2002-09-09 21:25:28 +00:00
outpkt = pkt [ nextpkt + + ] ;
2002-02-18 16:25:19 +00:00
2014-12-24 21:23:24 +00:00
if ( ( outpkt - > len = compress_packet ( DATA ( outpkt ) , DATA ( inpkt ) , inpkt - > len , n - > outcompression ) ) < 0 ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_ERR , " Error while compressing packet to %s (%s) " ,
2002-09-09 21:25:28 +00:00
n - > name , n - > hostname ) ;
return ;
}
2002-02-18 16:25:19 +00:00
2002-09-09 21:25:28 +00:00
inpkt = outpkt ;
}
2002-02-18 16:25:19 +00:00
2002-09-09 21:25:28 +00:00
/* Add sequence number */
2002-02-18 16:25:19 +00:00
2014-12-24 21:23:24 +00:00
seqno_t seqno = htonl ( + + ( n - > sent_seqno ) ) ;
memcpy ( SEQNO ( inpkt ) , & seqno , sizeof seqno ) ;
inpkt - > len + = sizeof seqno ;
2002-02-18 16:25:19 +00:00
2002-09-09 21:25:28 +00:00
/* Encrypt the packet */
2002-02-18 16:25:19 +00:00
2013-05-01 15:17:22 +00:00
if ( cipher_active ( n - > outcipher ) ) {
2002-09-09 21:25:28 +00:00
outpkt = pkt [ nextpkt + + ] ;
2008-12-11 14:44:44 +00:00
outlen = MAXSIZE ;
2002-02-18 16:25:19 +00:00
2014-12-24 21:23:24 +00:00
if ( ! cipher_encrypt ( n - > outcipher , SEQNO ( inpkt ) , inpkt - > len , SEQNO ( outpkt ) , & outlen , true ) ) {
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_ERR , " Error while encrypting packet to %s (%s) " , n - > name , n - > hostname ) ;
2003-12-24 10:48:15 +00:00
goto end ;
2003-10-10 16:24:24 +00:00
}
2002-02-18 16:25:19 +00:00
2008-12-11 14:44:44 +00:00
outpkt - > len = outlen ;
2002-09-09 21:25:28 +00:00
inpkt = outpkt ;
}
2002-03-18 22:47:20 +00:00
2002-09-09 21:25:28 +00:00
/* Add the message authentication code */
2002-03-18 22:47:20 +00:00
2013-05-01 15:17:22 +00:00
if ( digest_active ( n - > outdigest ) ) {
2014-12-24 21:23:24 +00:00
if ( ! digest_create ( n - > outdigest , SEQNO ( inpkt ) , inpkt - > len , SEQNO ( inpkt ) + inpkt - > len ) ) {
2013-05-10 18:30:47 +00:00
logger ( DEBUG_TRAFFIC , LOG_ERR , " Error while encrypting packet to %s (%s) " , n - > name , n - > hostname ) ;
goto end ;
}
2013-05-01 15:17:22 +00:00
inpkt - > len + = digest_length ( n - > outdigest ) ;
2002-09-09 21:25:28 +00:00
}
/* Send the packet */
2002-02-18 16:25:19 +00:00
2014-06-29 10:01:24 +00:00
const sockaddr_t * sa = NULL ;
2012-02-22 22:17:43 +00:00
int sock ;
2014-06-22 16:27:55 +00:00
if ( n - > status . send_locally )
choose_local_address ( n , & sa , & sock ) ;
2014-06-29 10:01:24 +00:00
if ( ! sa )
2012-11-17 21:48:06 +00:00
choose_udp_address ( n , & sa , & sock ) ;
2012-10-10 12:46:22 +00:00
2002-03-01 15:14:29 +00:00
# if defined(SOL_IP) && defined(IP_TOS)
2002-09-09 21:25:28 +00:00
if ( priorityinheritance & & origpriority ! = priority
2012-02-18 10:48:21 +00:00
& & listen_socket [ n - > sock ] . sa . sa . sa_family = = AF_INET ) {
2002-09-09 21:25:28 +00:00
priority = origpriority ;
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_DEBUG , " Setting outgoing packet priority to %d " , priority ) ;
2012-11-29 11:28:23 +00:00
if ( setsockopt ( listen_socket [ n - > sock ] . udp . fd , SOL_IP , IP_TOS , & priority , sizeof ( priority ) ) ) /* SO_PRIORITY doesn't seem to work */
2014-06-26 19:42:40 +00:00
logger ( DEBUG_ALWAYS , LOG_ERR , " System call `%s' failed: %s " , " setsockopt " , sockstrerror ( sockerrno ) ) ;
2002-09-09 21:25:28 +00:00
}
2002-03-01 15:14:29 +00:00
# endif
2002-03-01 12:26:56 +00:00
2014-12-24 21:23:24 +00:00
if ( sendto ( listen_socket [ sock ] . udp . fd , SEQNO ( inpkt ) , inpkt - > len , 0 , & sa - > sa , SALEN ( sa - > sa ) ) < 0 & & ! sockwouldblock ( sockerrno ) ) {
2009-10-24 23:40:07 +00:00
if ( sockmsgsize ( sockerrno ) ) {
2003-12-22 11:04:17 +00:00
if ( n - > maxmtu > = origlen )
n - > maxmtu = origlen - 1 ;
2003-12-20 19:47:53 +00:00
if ( n - > mtu > = origlen )
n - > mtu = origlen - 1 ;
2015-01-01 10:32:14 +00:00
try_fix_mtu ( n ) ;
2003-12-24 10:48:15 +00:00
} else
2012-03-08 20:15:08 +00:00
logger ( DEBUG_TRAFFIC , LOG_WARNING , " Error sending packet to %s (%s): %s " , n - > name , n - > hostname , sockstrerror ( sockerrno ) ) ;
2002-09-09 21:25:28 +00:00
}
2003-12-24 10:48:15 +00:00
end :
2006-04-26 16:29:47 +00:00
origpkt - > len = origlen ;
2014-12-29 21:57:18 +00:00
# endif
2002-02-18 16:25:19 +00:00
}
2015-05-09 16:54:34 +00:00
bool send_sptps_data ( node_t * to , node_t * from , int type , const void * data , size_t len ) {
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
node_t * relay = ( to - > via ! = myself & & ( type = = PKT_PROBE | | ( len - SPTPS_DATAGRAM_OVERHEAD ) < = to - > via - > minmtu ) ) ? to - > via : to - > nexthop ;
bool direct = from = = myself & & to = = relay ;
bool relay_supported = ( relay - > options > > 24 ) > = 4 ;
2014-10-04 14:01:11 +00:00
bool tcponly = ( myself - > options | relay - > options ) & OPTION_TCPONLY ;
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
/* Send it via TCP if it is a handshake packet, TCPOnly is in use, this is a relay packet that the other node cannot understand, or this packet is larger than the MTU. */
2012-10-14 12:33:54 +00:00
2014-10-04 14:01:11 +00:00
if ( type = = SPTPS_HANDSHAKE | | tcponly | | ( ! direct & & ! relay_supported ) | | ( type ! = PKT_PROBE & & ( len - SPTPS_DATAGRAM_OVERHEAD ) > relay - > minmtu ) ) {
2015-05-17 16:09:56 +00:00
if ( type ! = SPTPS_HANDSHAKE & & ( to - > nexthop - > connection - > options > > 24 ) > = 7 ) {
Introduce raw TCP SPTPS packet transport.
Currently, SPTPS packets are transported over TCP metaconnections using
extended REQ_KEY requests, in order for the packets to pass through
tinc-1.0 nodes unaltered. Unfortunately, this method presents two
significant downsides:
- An already encrypted SPTPS packet is decrypted and then encrypted
again every time it passes through a node, since it is transported
over the SPTPS channels of the metaconnections. This
double-encryption is unnecessary and wastes CPU cycles.
- More importantly, the only way to transport binary data over
standard metaconnection messages such as REQ_KEY is to encode it
in base64, which has a 33% encoding overhead. This wastes 25% of the
network bandwidth.
This commit introduces a new protocol message, SPTPS_PACKET, which can
be used to transport SPTPS packets over a TCP metaconnection in an
efficient way. The new message is appropriately protected through a
minor protocol version increment, and extended REQ_KEY messages are
still used with nodes that do not support the new message, as well as
for the intial handshake packets, for which efficiency is not a concern.
The way SPTPS_PACKET works is very similar to how the traditional PACKET
message works: after the SPTPS_PACKET message, the raw binary packet is
sent directly over the metaconnection. There is one important
difference, however: in the case of SPTPS_PACKET, the packet is sent
directly over the TCP stream completely bypassing the SPTPS channel of
the metaconnection itself for maximum efficiency. This is secure because
the SPTPS packet that is being sent is already encrypted with an
end-to-end key.
2015-05-10 18:00:03 +00:00
char buf [ len + sizeof to - > id + sizeof from - > id ] ; char * buf_ptr = buf ;
memcpy ( buf_ptr , & to - > id , sizeof to - > id ) ; buf_ptr + = sizeof to - > id ;
memcpy ( buf_ptr , & from - > id , sizeof from - > id ) ; buf_ptr + = sizeof from - > id ;
memcpy ( buf_ptr , data , len ) ; buf_ptr + = len ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending packet from %s (%s) to %s (%s) via %s (%s) (TCP) " , from - > name , from - > hostname , to - > name , to - > hostname , to - > nexthop - > name , to - > nexthop - > hostname ) ;
return send_sptps_tcppacket ( to - > nexthop - > connection , buf , sizeof buf ) ;
}
2012-07-30 16:36:59 +00:00
char buf [ len * 4 / 3 + 5 ] ;
b64encode ( data , buf , len ) ;
2015-05-17 16:09:56 +00:00
/* If this is a handshake packet, use ANS_KEY instead of REQ_KEY, for two reasons:
- We don ' t want intermediate nodes to switch to UDP to relay these packets ;
- ANS_KEY allows us to learn the reflexive UDP address . */
if ( type = = SPTPS_HANDSHAKE ) {
2013-07-24 18:48:31 +00:00
to - > incompression = myself - > incompression ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
return send_request ( to - > nexthop - > connection , " %d %s %s %s -1 -1 -1 %d " , ANS_KEY , from - > name , to - > name , buf , to - > incompression ) ;
2013-07-24 18:48:31 +00:00
} else {
2015-05-10 17:05:19 +00:00
return send_request ( to - > nexthop - > connection , " %d %s %s %d %s " , REQ_KEY , from - > name , to - > name , SPTPS_PACKET , buf ) ;
2013-07-24 18:48:31 +00:00
}
2012-07-30 16:36:59 +00:00
}
2014-09-27 17:13:33 +00:00
size_t overhead = 0 ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
if ( relay_supported ) overhead + = sizeof to - > id + sizeof from - > id ;
2014-09-27 17:13:33 +00:00
char buf [ len + overhead ] ; char * buf_ptr = buf ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
if ( relay_supported ) {
if ( direct ) {
/* Inform the recipient that this packet was sent directly. */
2014-12-03 13:51:45 +00:00
node_id_t nullid = { } ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
memcpy ( buf_ptr , & nullid , sizeof nullid ) ; buf_ptr + = sizeof nullid ;
} else {
memcpy ( buf_ptr , & to - > id , sizeof to - > id ) ; buf_ptr + = sizeof to - > id ;
}
memcpy ( buf_ptr , & from - > id , sizeof from - > id ) ; buf_ptr + = sizeof from - > id ;
2014-09-27 17:13:33 +00:00
}
/* TODO: if this copy turns out to be a performance concern, change sptps_send_record() to add some "pre-padding" to the buffer and use that instead */
memcpy ( buf_ptr , data , len ) ; buf_ptr + = len ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
const sockaddr_t * sa = NULL ;
int sock ;
if ( relay - > status . send_locally )
choose_local_address ( relay , & sa , & sock ) ;
if ( ! sa )
choose_udp_address ( relay , & sa , & sock ) ;
Introduce raw TCP SPTPS packet transport.
Currently, SPTPS packets are transported over TCP metaconnections using
extended REQ_KEY requests, in order for the packets to pass through
tinc-1.0 nodes unaltered. Unfortunately, this method presents two
significant downsides:
- An already encrypted SPTPS packet is decrypted and then encrypted
again every time it passes through a node, since it is transported
over the SPTPS channels of the metaconnections. This
double-encryption is unnecessary and wastes CPU cycles.
- More importantly, the only way to transport binary data over
standard metaconnection messages such as REQ_KEY is to encode it
in base64, which has a 33% encoding overhead. This wastes 25% of the
network bandwidth.
This commit introduces a new protocol message, SPTPS_PACKET, which can
be used to transport SPTPS packets over a TCP metaconnection in an
efficient way. The new message is appropriately protected through a
minor protocol version increment, and extended REQ_KEY messages are
still used with nodes that do not support the new message, as well as
for the intial handshake packets, for which efficiency is not a concern.
The way SPTPS_PACKET works is very similar to how the traditional PACKET
message works: after the SPTPS_PACKET message, the raw binary packet is
sent directly over the metaconnection. There is one important
difference, however: in the case of SPTPS_PACKET, the packet is sent
directly over the TCP stream completely bypassing the SPTPS channel of
the metaconnection itself for maximum efficiency. This is secure because
the SPTPS packet that is being sent is already encrypted with an
end-to-end key.
2015-05-10 18:00:03 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending packet from %s (%s) to %s (%s) via %s (%s) (UDP) " , from - > name , from - > hostname , to - > name , to - > hostname , relay - > name , relay - > hostname ) ;
2014-09-27 17:13:33 +00:00
if ( sendto ( listen_socket [ sock ] . udp . fd , buf , buf_ptr - buf , 0 , & sa - > sa , SALEN ( sa - > sa ) ) < 0 & & ! sockwouldblock ( sockerrno ) ) {
2012-07-30 16:36:59 +00:00
if ( sockmsgsize ( sockerrno ) ) {
2014-05-12 13:57:40 +00:00
// Compensate for SPTPS overhead
len - = SPTPS_DATAGRAM_OVERHEAD ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
if ( relay - > maxmtu > = len )
relay - > maxmtu = len - 1 ;
if ( relay - > mtu > = len )
relay - > mtu = len - 1 ;
2015-01-01 10:32:14 +00:00
try_fix_mtu ( relay ) ;
2012-07-30 16:36:59 +00:00
} else {
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
logger ( DEBUG_TRAFFIC , LOG_WARNING , " Error sending UDP SPTPS packet to %s (%s): %s " , relay - > name , relay - > hostname , sockstrerror ( sockerrno ) ) ;
2012-07-30 16:36:59 +00:00
return false ;
}
}
return true ;
}
2014-12-24 21:23:24 +00:00
bool receive_sptps_record ( void * handle , uint8_t type , const void * data , uint16_t len ) {
2012-07-30 16:36:59 +00:00
node_t * from = handle ;
if ( type = = SPTPS_HANDSHAKE ) {
2012-10-14 12:45:27 +00:00
if ( ! from - > status . validkey ) {
from - > status . validkey = true ;
from - > status . waitingforkey = false ;
logger ( DEBUG_META , LOG_INFO , " SPTPS key exchange with %s (%s) succesful " , from - > name , from - > hostname ) ;
}
2012-07-30 16:36:59 +00:00
return true ;
}
if ( len > MTU ) {
logger ( DEBUG_ALWAYS , LOG_ERR , " Packet from %s (%s) larger than maximum supported size (%d > %d) " , from - > name , from - > hostname , len , MTU ) ;
return false ;
}
vpn_packet_t inpkt ;
2014-12-24 21:23:24 +00:00
inpkt . offset = DEFAULT_PACKET_OFFSET ;
2012-07-30 16:36:59 +00:00
if ( type = = PKT_PROBE ) {
2015-01-11 16:44:50 +00:00
if ( ! from - > status . udppacket ) {
logger ( DEBUG_ALWAYS , LOG_ERR , " Got SPTPS PROBE packet from %s (%s) via TCP " , from - > name , from - > hostname ) ;
return false ;
}
2012-08-02 15:44:59 +00:00
inpkt . len = len ;
2014-12-24 21:23:24 +00:00
memcpy ( DATA ( & inpkt ) , data , len ) ;
2015-01-11 16:44:50 +00:00
if ( inpkt . len > from - > maxrecentlen )
from - > maxrecentlen = inpkt . len ;
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
udp_probe_h ( from , & inpkt , len ) ;
2012-07-30 16:36:59 +00:00
return true ;
}
2012-08-02 15:44:59 +00:00
if ( type & ~ ( PKT_COMPRESSED | PKT_MAC ) ) {
2012-07-30 16:36:59 +00:00
logger ( DEBUG_ALWAYS , LOG_ERR , " Unexpected SPTPS record type %d len %d from %s (%s) " , type , len , from - > name , from - > hostname ) ;
return false ;
}
2012-08-30 12:21:23 +00:00
/* Check if we have the headers we need */
if ( routing_mode ! = RMODE_ROUTER & & ! ( type & PKT_MAC ) ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " Received packet from %s (%s) without MAC header (maybe Mode is not set correctly) " , from - > name , from - > hostname ) ;
return false ;
} else if ( routing_mode = = RMODE_ROUTER & & ( type & PKT_MAC ) ) {
logger ( DEBUG_TRAFFIC , LOG_WARNING , " Received packet from %s (%s) with MAC header (maybe Mode is not set correctly) " , from - > name , from - > hostname ) ;
}
2012-08-02 15:44:59 +00:00
int offset = ( type & PKT_MAC ) ? 0 : 14 ;
if ( type & PKT_COMPRESSED ) {
2014-12-24 21:23:24 +00:00
length_t ulen = uncompress_packet ( DATA ( & inpkt ) + offset , ( const uint8_t * ) data , len , from - > incompression ) ;
2012-12-05 13:42:21 +00:00
if ( ulen < 0 ) {
2012-08-02 15:44:59 +00:00
return false ;
} else {
2012-12-05 13:42:21 +00:00
inpkt . len = ulen + offset ;
2012-08-02 15:44:59 +00:00
}
if ( inpkt . len > MAXSIZE )
abort ( ) ;
} else {
2014-12-24 21:23:24 +00:00
memcpy ( DATA ( & inpkt ) + offset , data , len ) ;
2012-08-02 15:44:59 +00:00
inpkt . len = len + offset ;
}
2012-08-30 12:21:23 +00:00
/* Generate the Ethernet packet type if necessary */
if ( offset ) {
2014-12-24 21:23:24 +00:00
switch ( DATA ( & inpkt ) [ 14 ] > > 4 ) {
2012-08-30 12:21:23 +00:00
case 4 :
2014-12-24 21:23:24 +00:00
DATA ( & inpkt ) [ 12 ] = 0x08 ;
DATA ( & inpkt ) [ 13 ] = 0x00 ;
2012-08-30 12:21:23 +00:00
break ;
case 6 :
2014-12-24 21:23:24 +00:00
DATA ( & inpkt ) [ 12 ] = 0x86 ;
DATA ( & inpkt ) [ 13 ] = 0xDD ;
2012-08-30 12:21:23 +00:00
break ;
default :
logger ( DEBUG_TRAFFIC , LOG_ERR ,
" Unknown IP version %d while reading packet from %s (%s) " ,
2014-12-24 21:23:24 +00:00
DATA ( & inpkt ) [ 14 ] > > 4 , from - > name , from - > hostname ) ;
2012-08-30 12:21:23 +00:00
return false ;
}
}
2015-01-11 16:44:50 +00:00
if ( from - > status . udppacket & & inpkt . len > from - > maxrecentlen )
from - > maxrecentlen = inpkt . len ;
2012-07-30 16:36:59 +00:00
receive_packet ( from , & inpkt ) ;
return true ;
}
2014-12-28 17:29:03 +00:00
// This function tries to get SPTPS keys, if they aren't already known.
// This function makes no guarantees - it is up to the caller to check the node's state to figure out if the keys are available.
static void try_sptps ( node_t * n ) {
if ( n - > status . validkey )
return ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " No valid key known yet for %s (%s) " , n - > name , n - > hostname ) ;
if ( ! n - > status . waitingforkey )
send_req_key ( n ) ;
else if ( n - > last_req_key + 10 < now . tv_sec ) {
logger ( DEBUG_ALWAYS , LOG_DEBUG , " No key from %s after 10 seconds, restarting SPTPS " , n - > name ) ;
sptps_stop ( & n - > sptps ) ;
n - > status . waitingforkey = false ;
send_req_key ( n ) ;
}
return ;
}
2014-12-29 17:05:19 +00:00
static void send_udp_probe_packet ( node_t * n , int len ) {
vpn_packet_t packet ;
packet . offset = DEFAULT_PACKET_OFFSET ;
memset ( DATA ( & packet ) , 0 , 14 ) ;
randomize ( DATA ( & packet ) + 14 , len - 14 ) ;
packet . len = len ;
packet . priority = 0 ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending UDP probe length %d to %s (%s) " , len , n - > name , n - > hostname ) ;
send_udppacket ( n , & packet ) ;
}
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
// This function tries to establish a UDP tunnel to a node so that packets can be sent.
// If a tunnel is already established, it makes sure it stays up.
// This function makes no guarantees - it is up to the caller to check the node's state to figure out if UDP is usable.
static void try_udp ( node_t * n ) {
if ( ! udp_discovery )
return ;
2015-01-11 16:44:50 +00:00
/* Send gratuitous probe replies to 1.1 nodes. */
if ( ( n - > options > > 24 ) > = 3 & & n - > status . udp_confirmed ) {
struct timeval ping_tx_elapsed ;
timersub ( & now , & n - > udp_reply_sent , & ping_tx_elapsed ) ;
if ( ping_tx_elapsed . tv_sec > = udp_discovery_keepalive_interval - 1 ) {
n - > udp_reply_sent = now ;
if ( n - > maxrecentlen ) {
vpn_packet_t pkt ;
pkt . len = n - > maxrecentlen ;
pkt . offset = DEFAULT_PACKET_OFFSET ;
memset ( DATA ( & pkt ) , 0 , 14 ) ;
randomize ( DATA ( & pkt ) + 14 , MIN_PROBE_SIZE - 14 ) ;
send_udp_probe_reply ( n , & pkt , pkt . len ) ;
n - > maxrecentlen = 0 ;
}
}
}
/* Probe request */
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
struct timeval ping_tx_elapsed ;
timersub ( & now , & n - > udp_ping_sent , & ping_tx_elapsed ) ;
2015-01-03 10:05:57 +00:00
int interval = n - > status . udp_confirmed ? udp_discovery_keepalive_interval : udp_discovery_interval ;
if ( ping_tx_elapsed . tv_sec > = interval ) {
2015-01-11 12:53:16 +00:00
send_udp_probe_packet ( n , MIN_PROBE_SIZE ) ;
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
n - > udp_ping_sent = now ;
2014-12-29 15:40:55 +00:00
if ( localdiscovery & & ! n - > status . udp_confirmed & & n - > prevedge ) {
n - > status . send_locally = true ;
2015-01-11 12:53:16 +00:00
send_udp_probe_packet ( n , MIN_PROBE_SIZE ) ;
2014-12-29 15:40:55 +00:00
n - > status . send_locally = false ;
}
Add UDP discovery mechanism.
This adds a new mechanism by which tinc can determine if a node is
reachable via UDP. The new mechanism is currently redundant with the
PMTU discovery mechanism - that will be fixed in a future commit.
Conceptually, the UDP discovery mechanism works similarly to PMTU
discovery: it sends UDP probes (of minmtu size, to make sure the tunnel
is fully usable), and assumes UDP is usable if it gets replies. It
assumes UDP is broken if too much time has passed since the last reply.
The big difference with the current PMTU discovery mechanism, however,
is that UDP discovery probes are only triggered as part of the
packet TX path (through try_tx()). This is quite interesting, because
it means tinc will never send UDP pings more often than normal packets,
and most importantly, it will automatically stop sending pings as soon
as packets stop flowing, thereby nicely reducing network chatter.
Of course, there are small drawbacks in some edge cases: for example,
if a node only sends one packet every minute to another node, these
packets will only be sent over TCP, because the interval between packets
is too long for tinc to maintain the UDP tunnel. I consider this a
feature, not a bug: I believe it is appropriate to use TCP in scenarios
where traffic is negligible, so that we don't pollute the network with
pings just to maintain a UDP tunnel that's seeing negligible usage.
2014-12-29 10:34:39 +00:00
}
}
2014-12-31 16:12:11 +00:00
static length_t choose_initial_maxmtu ( node_t * n ) {
# ifdef IP_MTU
int sock = - 1 ;
const sockaddr_t * sa = NULL ;
int sockindex ;
choose_udp_address ( n , & sa , & sockindex ) ;
if ( ! sa )
return MTU ;
sock = socket ( sa - > sa . sa_family , SOCK_DGRAM , IPPROTO_UDP ) ;
if ( sock < 0 ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " Creating MTU assessment socket for %s (%s) failed: %s " , n - > name , n - > hostname , sockstrerror ( sockerrno ) ) ;
return MTU ;
}
if ( connect ( sock , & sa - > sa , SALEN ( sa - > sa ) ) ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " Connecting MTU assessment socket for %s (%s) failed: %s " , n - > name , n - > hostname , sockstrerror ( sockerrno ) ) ;
close ( sock ) ;
return MTU ;
}
int ip_mtu ;
socklen_t ip_mtu_len = sizeof ip_mtu ;
if ( getsockopt ( sock , IPPROTO_IP , IP_MTU , & ip_mtu , & ip_mtu_len ) ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " getsockopt(IP_MTU) on %s (%s) failed: %s " , n - > name , n - > hostname , sockstrerror ( sockerrno ) ) ;
close ( sock ) ;
return MTU ;
}
close ( sock ) ;
/* getsockopt(IP_MTU) returns the MTU of the physical interface.
We need to remove various overheads to get to the tinc MTU . */
length_t mtu = ip_mtu ;
mtu - = ( sa - > sa . sa_family = = AF_INET6 ) ? sizeof ( struct ip6_hdr ) : sizeof ( struct ip ) ;
mtu - = 8 ; /* UDP */
if ( n - > status . sptps ) {
mtu - = SPTPS_DATAGRAM_OVERHEAD ;
if ( ( n - > options > > 24 ) > = 4 )
mtu - = sizeof ( node_id_t ) + sizeof ( node_id_t ) ;
2015-02-17 03:02:35 +00:00
# ifndef DISABLE_LEGACY
2015-01-10 22:00:51 +00:00
} else {
mtu - = digest_length ( n - > outdigest ) ;
/* Now it's tricky. We use CBC mode, so the length of the
encrypted payload must be a multiple of the blocksize . The
sequence number is also part of the encrypted payload , so we
must account for it after correcting for the blocksize .
Furthermore , the padding in the last block must be at least
1 byte . */
length_t blocksize = cipher_blocksize ( n - > outcipher ) ;
if ( blocksize > 1 ) {
mtu / = blocksize ;
mtu * = blocksize ;
mtu - - ;
}
mtu - = 4 ; // seqno
2015-02-17 03:02:35 +00:00
# endif
2014-12-31 16:12:11 +00:00
}
if ( mtu < 512 ) {
logger ( DEBUG_TRAFFIC , LOG_ERR , " getsockopt(IP_MTU) on %s (%s) returned absurdly small value: %d " , n - > name , n - > hostname , ip_mtu ) ;
return MTU ;
}
if ( mtu > MTU )
return MTU ;
logger ( DEBUG_TRAFFIC , LOG_INFO , " Using system-provided maximum tinc MTU for %s (%s): %hd " , n - > name , n - > hostname , mtu ) ;
return mtu ;
# else
return MTU ;
# endif
}
2015-01-10 21:28:47 +00:00
/* This function tries to determines the MTU of a node.
By calling this function repeatedly , n - > minmtu will be progressively
increased , and at some point , n - > mtu will be fixed to n - > minmtu . If the MTU
is already fixed , this function checks if it can be increased .
*/
2014-12-29 17:05:19 +00:00
static void try_mtu ( node_t * n ) {
if ( ! ( n - > options & OPTION_PMTU_DISCOVERY ) )
return ;
if ( udp_discovery & & ! n - > status . udp_confirmed ) {
2015-01-11 15:10:58 +00:00
n - > maxrecentlen = 0 ;
2014-12-29 17:05:19 +00:00
n - > mtuprobes = 0 ;
n - > minmtu = 0 ;
n - > maxmtu = MTU ;
return ;
}
2014-12-30 17:02:38 +00:00
/* mtuprobes == 0..19: initial discovery, send bursts with 1 second interval, mtuprobes++
mtuprobes = = 20 : fix MTU , and go to - 1
2015-01-11 14:38:56 +00:00
mtuprobes = = - 1 : send one maxmtu and one maxmtu + 1 probe every pinginterval
mtuprobes = = - 2. . - 3 : send one maxmtu probe every second
mtuprobes = = - 4 : maxmtu no longer valid , reset minmtu and maxmtu and go to 0 */
2014-12-29 17:05:19 +00:00
struct timeval elapsed ;
2015-01-11 13:44:15 +00:00
timersub ( & now , & n - > mtu_ping_sent , & elapsed ) ;
2015-01-01 16:04:08 +00:00
if ( n - > mtuprobes > = 0 ) {
2014-12-30 10:16:32 +00:00
if ( n - > mtuprobes ! = 0 & & elapsed . tv_sec = = 0 & & elapsed . tv_usec < 333333 )
2014-12-29 17:05:19 +00:00
return ;
} else {
2015-01-11 14:38:56 +00:00
if ( n - > mtuprobes < - 1 ) {
if ( elapsed . tv_sec < 1 )
return ;
} else {
if ( elapsed . tv_sec < pinginterval )
return ;
}
2014-12-29 17:05:19 +00:00
}
2015-01-11 13:44:15 +00:00
n - > mtu_ping_sent = now ;
2015-01-01 10:32:14 +00:00
try_fix_mtu ( n ) ;
2014-12-29 17:05:19 +00:00
2015-01-11 14:38:56 +00:00
if ( n - > mtuprobes < - 3 ) {
/* We lost three MTU probes, restart discovery */
logger ( DEBUG_TRAFFIC , LOG_INFO , " Decrease in PMTU to %s (%s) detected, restarting PMTU discovery " , n - > name , n - > hostname ) ;
n - > mtuprobes = 0 ;
n - > minmtu = 0 ;
}
2015-01-01 16:04:08 +00:00
if ( n - > mtuprobes < 0 ) {
2015-01-11 12:53:16 +00:00
/* After the initial discovery, we only send one maxmtu and one
maxmtu + 1 probe to detect PMTU increases . */
send_udp_probe_packet ( n , n - > maxmtu ) ;
2015-01-11 14:38:56 +00:00
if ( n - > mtuprobes = = - 1 & & n - > maxmtu + 1 < MTU )
2014-12-30 17:02:38 +00:00
send_udp_probe_packet ( n , n - > maxmtu + 1 ) ;
2015-01-11 14:38:56 +00:00
n - > mtuprobes - - ;
2014-12-29 17:05:19 +00:00
} else {
2014-12-31 16:12:11 +00:00
/* Before initial discovery begins, set maxmtu to the most likely value.
If it ' s underestimated , we will correct it after initial discovery . */
if ( n - > mtuprobes = = 0 )
n - > maxmtu = choose_initial_maxmtu ( n ) ;
2015-01-01 16:59:45 +00:00
for ( ; ; ) {
/* Decreasing the number of probes per cycle might make the algorithm react faster to lost packets,
but it will typically increase convergence time in the no - loss case . */
const length_t probes_per_cycle = 8 ;
/* This magic value was determined using math simulations.
It will result in a 1329 - byte first probe , followed ( if there was a reply ) by a 1407 - byte probe .
Since 1407 is just below the range of tinc MTUs over typical networks ,
this fine - tuning allows tinc to cover a lot of ground very quickly .
This fine - tuning is only valid for maxmtu = MTU ; if maxmtu is smaller ,
then it ' s better to use a multiplier of 1. Indeed , this leads to an interesting scenario
if choose_initial_maxmtu ( ) returns the actual MTU value - it will get confirmed with one single probe . */
const float multiplier = ( n - > maxmtu = = MTU ) ? 0.97 : 1 ;
const float cycle_position = probes_per_cycle - ( n - > mtuprobes % probes_per_cycle ) - 1 ;
const length_t minmtu = MAX ( n - > minmtu , 512 ) ;
const float interval = n - > maxmtu - minmtu ;
/* The core of the discovery algorithm is this exponential.
It produces very large probes early in the cycle , and then it very quickly decreases the probe size .
This reflects the fact that in the most difficult cases , we don ' t get any feedback for probes that
are too large , and therefore we need to concentrate on small offsets so that we can quickly converge
on the precise MTU as we are approaching it .
The last probe of the cycle is always 1 byte in size - this is to make sure we ' ll get at least one
reply per cycle so that we can make progress . */
const length_t offset = powf ( interval , multiplier * cycle_position / ( probes_per_cycle - 1 ) ) ;
length_t maxmtu = n - > maxmtu ;
send_udp_probe_packet ( n , minmtu + offset ) ;
/* If maxmtu changed, it means the probe was rejected by the system because it was too large.
In that case , we recalculate with the new maxmtu and try again . */
if ( n - > mtuprobes < 0 | | maxmtu = = n - > maxmtu )
break ;
}
2015-01-01 10:32:14 +00:00
if ( n - > mtuprobes > = 0 )
n - > mtuprobes + + ;
2014-12-29 17:05:19 +00:00
}
}
2015-01-10 21:28:47 +00:00
/* These functions try to establish a tunnel to a node (or its relay) so that
packets can be sent ( e . g . exchange keys ) .
If a tunnel is already established , it tries to improve it ( e . g . by trying
to establish a UDP tunnel instead of TCP ) . This function makes no
guarantees - it is up to the caller to check the node ' s state to figure out
if TCP and / or UDP is usable . By calling this function repeatedly , the
tunnel is gradually improved until we hit the wall imposed by the underlying
network environment . It is recommended to call this function every time a
packet is sent ( or intended to be sent ) to a node , so that the tunnel keeps
improving as packets flow , and then gracefully downgrades itself as it goes
idle .
*/
2015-01-11 12:31:01 +00:00
static void try_tx_sptps ( node_t * n , bool mtu ) {
2014-12-28 17:16:27 +00:00
/* If n is a TCP-only neighbor, we'll only use "cleartext" PACKET
2015-01-10 21:28:47 +00:00
messages anyway , so there ' s no need for SPTPS at all . */
if ( n - > connection & & ( ( myself - > options | n - > options ) & OPTION_TCPONLY ) )
return ;
/* Otherwise, try to do SPTPS authentication with n if necessary. */
try_sptps ( n ) ;
2015-03-08 14:20:15 +00:00
/* Do we need to statically relay packets? */
2014-12-28 17:16:27 +00:00
node_t * via = ( n - > via = = myself ) ? n - > nexthop : n - > via ;
2015-01-10 21:28:47 +00:00
2015-05-18 20:06:16 +00:00
/* If we do have a static relay, try everything with that one instead, if it supports relaying. */
2015-01-10 21:28:47 +00:00
2015-05-18 20:06:16 +00:00
if ( via ! = n ) {
if ( ( via - > options > > 24 ) < 4 )
return ;
2015-03-14 14:04:50 +00:00
return try_tx_sptps ( via , mtu ) ;
2015-05-18 20:06:16 +00:00
}
2015-03-08 14:20:15 +00:00
/* Otherwise, try to establish UDP connectivity. */
2015-01-10 21:28:47 +00:00
try_udp ( n ) ;
2015-01-11 12:31:01 +00:00
if ( mtu )
try_mtu ( n ) ;
2015-03-08 14:20:15 +00:00
/* If we don't have UDP connectivity (yet), we need to use a dynamic relay (nexthop)
while we try to establish direct connectivity . */
if ( ! n - > status . udp_confirmed & & n ! = n - > nexthop & & ( n - > nexthop - > options > > 24 ) > = 4 )
try_tx_sptps ( n - > nexthop , mtu ) ;
2015-01-10 21:28:47 +00:00
}
2015-01-11 12:31:01 +00:00
static void try_tx_legacy ( node_t * n , bool mtu ) {
2015-01-10 22:52:23 +00:00
/* Does he have our key? If not, send one. */
if ( ! n - > status . validkey_in )
send_ans_key ( n ) ;
2015-01-10 21:28:47 +00:00
/* Check if we already have a key, or request one. */
if ( ! n - > status . validkey ) {
if ( n - > last_req_key + 10 < = now . tv_sec ) {
send_req_key ( n ) ;
n - > last_req_key = now . tv_sec ;
}
return ;
Move PMTU discovery code into the TX path.
Currently, the PMTU discovery code is run by a timeout callback,
independently of tunnel activity. This commit moves it into the TX
path, meaning that send_mtu_probe_handler() is only called if a
packet is about to be sent. Consequently, it has been renamed to
try_mtu() for consistency with try_tx(), try_udp() and try_sptps().
Running PMTU discovery code only as part of the TX path prevents
PMTU discovery from generating unreasonable amounts of traffic when
the "real" traffic is negligible. One extreme example is sending one
real packet and then going silent: in the current code this one little
packet will result in the entire PMTU discovery algorithm being run
from start to finish, resulting in absurd write traffic amplification.
With this patch, PMTU discovery stops as soon as "real" packets stop
flowing, and will be no more aggressive than the underlying traffic.
Furthermore, try_mtu() only runs if there is confirmed UDP
connectivity as per the UDP discovery mechanism. This prevents
unnecessary network chatter - previously, the PMTU discovery code
would send bursts of (potentially large) probe packets every second
even if there was nothing on the other side. With this patch, the
PMTU code only does that if something replied to the lightweight UDP
discovery pings.
These inefficiencies were made even worse when the node is not a
direct neighbour, as tinc will use PMTU discovery both on the
destination node *and* the relay. UDP discovery is more lightweight for
this purpose.
As a bonus, this code simplifies overall code somewhat - state is
easier to manage when code is run in predictable contexts as opposed
to "surprise callbacks". In addition, there is no need to call PMTU
discovery code outside of net_packet.c anymore, thereby simplifying
module boundaries.
2014-12-29 16:47:49 +00:00
}
2014-12-28 17:16:27 +00:00
2015-01-10 21:28:47 +00:00
try_udp ( n ) ;
2015-01-11 12:31:01 +00:00
if ( mtu )
try_mtu ( n ) ;
}
void try_tx ( node_t * n , bool mtu ) {
if ( n - > status . sptps )
try_tx_sptps ( n , mtu ) ;
else
try_tx_legacy ( n , mtu ) ;
2014-12-28 17:16:27 +00:00
}
2011-05-14 22:42:29 +00:00
void send_packet ( node_t * n , vpn_packet_t * packet ) {
2015-01-10 21:28:47 +00:00
// If it's for myself, write it to the tun/tap device.
2002-09-09 21:25:28 +00:00
if ( n = = myself ) {
2003-12-27 16:32:52 +00:00
if ( overwrite_mac )
2014-12-24 21:23:24 +00:00
memcpy ( DATA ( packet ) , mymac . x , ETH_ALEN ) ;
2011-05-14 22:42:29 +00:00
n - > out_packets + + ;
n - > out_bytes + = packet - > len ;
2011-12-04 00:20:59 +00:00
devops . write ( packet ) ;
2002-09-09 21:25:28 +00:00
return ;
}
2015-01-10 21:28:47 +00:00
logger ( DEBUG_TRAFFIC , LOG_ERR , " Sending packet of %d bytes to %s (%s) " , packet - > len , n - > name , n - > hostname ) ;
// If the node is not reachable, drop it.
2003-12-12 19:52:25 +00:00
2002-09-09 21:25:28 +00:00
if ( ! n - > status . reachable ) {
2015-01-10 21:28:47 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Node %s (%s) is not reachable " , n - > name , n - > hostname ) ;
2002-09-09 21:25:28 +00:00
return ;
}
2015-01-10 21:28:47 +00:00
// Keep track of packet statistics.
2011-05-14 22:42:29 +00:00
n - > out_packets + + ;
n - > out_bytes + = packet - > len ;
2015-01-10 21:28:47 +00:00
// Check if it should be sent as an SPTPS packet.
2012-08-02 15:44:59 +00:00
if ( n - > status . sptps ) {
send_sptps_packet ( n , packet ) ;
2015-01-11 12:31:01 +00:00
try_tx_sptps ( n , true ) ;
2015-01-10 21:28:47 +00:00
return ;
2012-08-02 15:44:59 +00:00
}
2015-01-10 21:28:47 +00:00
// Determine which node to actually send it to.
node_t * via = ( packet - > priority = = - 1 | | n - > via = = myself ) ? n - > nexthop : n - > via ;
2002-09-09 21:25:28 +00:00
2003-07-06 22:11:37 +00:00
if ( via ! = n )
2015-01-10 21:28:47 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Sending packet to %s via %s (%s) " , n - > name , via - > name , n - > via - > hostname ) ;
// Try to send via UDP, unless TCP is forced.
2002-09-09 21:25:28 +00:00
2009-01-03 21:33:55 +00:00
if ( packet - > priority = = - 1 | | ( ( myself - > options | via - > options ) & OPTION_TCPONLY ) ) {
2003-07-22 20:55:21 +00:00
if ( ! send_tcppacket ( via - > connection , packet ) )
terminate_connection ( via - > connection , true ) ;
2015-01-10 21:28:47 +00:00
return ;
}
2014-12-28 17:16:27 +00:00
2015-01-10 21:28:47 +00:00
send_udppacket ( via , packet ) ;
2015-01-11 12:31:01 +00:00
try_tx_legacy ( via , true ) ;
2002-02-18 16:25:19 +00:00
}
2007-05-18 10:00:00 +00:00
void broadcast_packet ( const node_t * from , vpn_packet_t * packet ) {
2012-04-15 23:57:25 +00:00
// Always give ourself a copy of the packet.
if ( from ! = myself )
send_packet ( myself , packet ) ;
// In TunnelServer mode, do not forward broadcast packets.
2012-10-10 15:17:49 +00:00
// The MST might not be valid and create loops.
2012-04-15 23:57:25 +00:00
if ( tunnelserver | | broadcast_mode = = BMODE_NONE )
return ;
2002-09-09 21:25:28 +00:00
2012-02-26 17:37:36 +00:00
logger ( DEBUG_TRAFFIC , LOG_INFO , " Broadcasting packet of %d bytes from %s (%s) " ,
2002-09-09 21:25:28 +00:00
packet - > len , from - > name , from - > hostname ) ;
2012-04-15 23:57:25 +00:00
switch ( broadcast_mode ) {
// In MST mode, broadcast packets travel via the Minimum Spanning Tree.
// This guarantees all nodes receive the broadcast packet, and
// usually distributes the sending of broadcast packets over all nodes.
case BMODE_MST :
2012-10-07 22:35:38 +00:00
for list_each ( connection_t , c , connection_list )
2014-07-12 10:57:03 +00:00
if ( c - > edge & & c - > status . mst & & c ! = from - > nexthop - > connection )
2012-04-15 23:57:25 +00:00
send_packet ( c - > node , packet ) ;
break ;
// In direct mode, we send copies to each node we know of.
2012-10-10 15:17:49 +00:00
// However, this only reaches nodes that can be reached in a single hop.
2012-04-15 23:57:25 +00:00
// We don't have enough information to forward broadcast packets in this case.
case BMODE_DIRECT :
if ( from ! = myself )
break ;
2012-10-07 22:35:38 +00:00
for splay_each ( node_t , n , node_tree )
2013-08-08 15:40:15 +00:00
if ( n - > status . reachable & & n ! = myself & & ( ( n - > via = = myself & & n - > nexthop = = n ) | | n - > via = = n ) )
2012-06-25 17:03:54 +00:00
send_packet ( n , packet ) ;
2012-04-15 23:57:25 +00:00
break ;
2002-09-09 21:25:28 +00:00
2012-04-15 23:57:25 +00:00
default :
break ;
2002-09-09 21:25:28 +00:00
}
2002-02-18 16:25:19 +00:00
}
2015-01-12 13:43:32 +00:00
/* We got a packet from some IP address, but we don't know who sent it. Try to
verify the message authentication code against all active session keys .
Since this is actually an expensive operation , we only do a full check once
a minute , the rest of the time we only check against nodes for which we know
an IP address that matches the one from the packet . */
2009-04-02 23:05:23 +00:00
static node_t * try_harder ( const sockaddr_t * from , const vpn_packet_t * pkt ) {
2015-01-12 13:43:32 +00:00
node_t * match = NULL ;
2011-02-18 22:02:11 +00:00
bool hard = false ;
2009-10-24 18:54:44 +00:00
static time_t last_hard_try = 0 ;
2009-04-02 23:05:23 +00:00
2015-01-12 13:43:32 +00:00
for splay_each ( node_t , n , node_tree ) {
if ( ! n - > status . reachable | | n = = myself )
continue ;
2015-05-18 19:35:44 +00:00
if ( ! n - > status . validkey_in & & ! ( n - > status . sptps & & n - > sptps . instate ) )
2009-04-02 23:05:23 +00:00
continue ;
2015-01-12 13:43:32 +00:00
bool soft = false ;
for splay_each ( edge_t , e , n - > edge_tree ) {
if ( ! e - > reverse )
continue ;
if ( ! sockaddrcmp_noport ( from , & e - > reverse - > address ) ) {
soft = true ;
break ;
}
}
if ( ! soft ) {
2012-11-29 11:28:23 +00:00
if ( last_hard_try = = now . tv_sec )
2009-10-24 18:54:44 +00:00
continue ;
2011-02-18 22:02:11 +00:00
hard = true ;
2009-12-18 00:15:25 +00:00
}
2009-04-02 23:05:23 +00:00
2015-01-12 13:43:32 +00:00
if ( ! try_mac ( n , pkt ) )
2009-04-02 23:05:23 +00:00
continue ;
2015-01-12 13:43:32 +00:00
match = n ;
2009-04-02 23:05:23 +00:00
break ;
}
2011-02-18 22:02:11 +00:00
if ( hard )
2012-11-29 11:28:23 +00:00
last_hard_try = now . tv_sec ;
2011-02-18 22:02:11 +00:00
2015-01-12 13:43:32 +00:00
return match ;
2009-04-02 23:05:23 +00:00
}
2012-11-29 11:28:23 +00:00
void handle_incoming_vpn_data ( void * data , int flags ) {
listen_socket_t * ls = data ;
2002-09-09 21:25:28 +00:00
vpn_packet_t pkt ;
char * hostname ;
2014-12-07 23:58:09 +00:00
node_id_t nullid = { } ;
sockaddr_t addr = { } ;
socklen_t addrlen = sizeof addr ;
node_t * from , * to ;
bool direct = false ;
2002-09-09 21:25:28 +00:00
2014-12-24 21:23:24 +00:00
pkt . offset = 0 ;
int len = recvfrom ( ls - > udp . fd , DATA ( & pkt ) , MAXSIZE , 0 , & addr . sa , & addrlen ) ;
2002-09-09 21:25:28 +00:00
2009-12-19 19:52:19 +00:00
if ( len < = 0 | | len > MAXSIZE ) {
2009-10-24 23:40:07 +00:00
if ( ! sockwouldblock ( sockerrno ) )
2012-02-26 17:37:36 +00:00
logger ( DEBUG_ALWAYS , LOG_ERR , " Receiving packet failed: %s " , sockstrerror ( sockerrno ) ) ;
2002-09-09 21:25:28 +00:00
return ;
}
2009-12-19 19:52:19 +00:00
pkt . len = len ;
2014-12-07 23:58:09 +00:00
sockaddrunmap ( & addr ) ; /* Some braindead IPv6 implementations do stupid things. */
2002-09-09 21:25:28 +00:00
2014-12-07 23:58:09 +00:00
// Try to figure out who sent this packet.
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
2014-12-07 23:58:09 +00:00
node_t * n = lookup_node_udp ( & addr ) ;
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
2015-01-12 13:43:32 +00:00
if ( n & & ! n - > status . udp_confirmed )
n = NULL ; // Don't believe it if we don't have confirmation yet.
Add UDP datagram relay support to SPTPS.
This commit changes the layout of UDP datagrams to include a 6-byte
destination node ID at the very beginning of the datagram (i.e. before
the source node ID and the seqno). Note that this only applies to SPTPS.
Thanks to this new field, it is now possible to send SPTPS datagrams to
nodes that are not the final recipient of the packets, thereby using
these nodes as relay nodes. Previously SPTPS was unable to relay packets
using UDP, and required a fallback to TCP if the final recipient could
not be contacted directly using UDP. In that sense it fixes a regression
that SPTPS introduced with regard to the legacy protocol.
This change also updates tinc's low-level routing logic (i.e.
send_sptps_data()) to automatically use this relaying facility if at all
possible. Specifically, it will relay packets if we don't have a
confirmed UDP link to the final recipient (but we have one with the next
hop node), or if IndirectData is specified. This is similar to how the
legacy protocol forwards packets.
When sending packets directly without any relaying, the sender node uses
a special value for the destination node ID: instead of setting the
field to the ID of the recipient node, it writes a zero ID instead. This
allows the recipient node to distinguish between a relayed packet and a
direct packet, which is important when determining the UDP address of
the sending node.
On the relay side, relay nodes will happily relay packets that have a
destination ID which is non-zero *and* is different from their own,
provided that the source IP address of the packet is known. This is to
prevent abuse by random strangers, since a node can't authenticate the
packets that are being relayed through it.
This change keeps the protocol number from the previous datagram format
change (source IDs), 17.4. Compatibility is still preserved with 1.0 and
with pre-1.1 releases. Note, however, that nodes running this code won't
understand datagrams sent from nodes that only use source IDs and
vice-versa (not that we really care).
There is one caveat: in the current state, there is no way for the
original sender to know what the PMTU is beyond the first hop, and
contrary to the legacy protocol, relay nodes can't apply MSS clamping
because they can't decrypt the relayed packets. This leads to
inefficient scenarios where a reduced PMTU over some link that's part of
the relay path will result in relays falling back to TCP to send packets
to their final destinations.
Another caveat is that once a packet gets sent over TCP, it will use
TCP over the entire path, even if it is technically possible to use UDP
beyond the TCP-only link(s).
Arguably, these two caveats can be fixed by improving the
metaconnection protocol, but that's out of scope for this change. TODOs
are added instead. In any case, this is no worse than before.
In addition, this change increases SPTPS datagram overhead by another
6 bytes for the destination ID, on top of the existing 6-byte overhead
from the source ID.
2014-09-28 11:38:06 +00:00
if ( ! n ) {
2014-12-07 23:58:09 +00:00
// It might be from a 1.1 node, which might have a source ID in the packet.
2014-12-24 21:23:24 +00:00
pkt . offset = 2 * sizeof ( node_id_t ) ;
from = lookup_node_id ( SRCID ( & pkt ) ) ;
if ( from & & ! memcmp ( DSTID ( & pkt ) , & nullid , sizeof nullid ) & & from - > status . sptps ) {
if ( sptps_verify_datagram ( & from - > sptps , DATA ( & pkt ) , pkt . len - 2 * sizeof ( node_id_t ) ) )
2014-12-07 23:58:09 +00:00
n = from ;
else
goto skip_harder ;
}
2014-09-27 17:13:33 +00:00
}
2002-09-09 21:25:28 +00:00
2014-12-24 21:23:24 +00:00
if ( ! n ) {
pkt . offset = 0 ;
2014-12-07 23:58:09 +00:00
n = try_harder ( & addr , & pkt ) ;
2014-12-24 21:23:24 +00:00
}
2014-09-27 17:13:33 +00:00
2014-12-07 23:58:09 +00:00
skip_harder :
2014-09-27 17:13:33 +00:00
if ( ! n ) {
if ( debug_level > = DEBUG_PROTOCOL ) {
2014-12-07 23:58:09 +00:00
hostname = sockaddr2hostname ( & addr ) ;
2012-02-26 17:37:36 +00:00
logger ( DEBUG_PROTOCOL , LOG_WARNING , " Received UDP packet from unknown source %s " , hostname ) ;
2009-04-02 23:05:23 +00:00
free ( hostname ) ;
}
2014-09-27 17:13:33 +00:00
return ;
2002-09-09 21:25:28 +00:00
}
2015-05-18 19:48:45 +00:00
pkt . offset = 0 ;
2014-12-07 23:58:09 +00:00
if ( n - > status . sptps ) {
2015-05-18 19:48:45 +00:00
bool relay_enabled = ( n - > options > > 24 ) > = 4 ;
if ( relay_enabled ) {
pkt . offset = 2 * sizeof ( node_id_t ) ;
pkt . len - = pkt . offset ;
}
2014-12-24 21:23:24 +00:00
2015-05-18 19:48:45 +00:00
if ( ! memcmp ( DSTID ( & pkt ) , & nullid , sizeof nullid ) | | ! relay_enabled ) {
2014-12-07 23:58:09 +00:00
direct = true ;
from = n ;
to = myself ;
} else {
2014-12-24 21:23:24 +00:00
from = lookup_node_id ( SRCID ( & pkt ) ) ;
to = lookup_node_id ( DSTID ( & pkt ) ) ;
2014-12-07 23:58:09 +00:00
}
if ( ! from | | ! to ) {
logger ( DEBUG_PROTOCOL , LOG_WARNING , " Received UDP packet from %s (%s) with unknown source and/or destination ID " , n - > name , n - > hostname ) ;
return ;
}
2014-12-08 07:43:15 +00:00
Add UDP_INFO protocol message.
In this commit, nodes use UDP_INFO messages to provide UDP address
information. The basic principle is that the node that receives packets
sends UDP_INFO messages to the node that's sending the packets. The
message originally contains no address information, and is (hopefully)
updated with relevant address information as it gets relayed through the
metagraph - specifically, each intermediate node will update the message
with its best guess as to what the address is while forwarding it.
When a node receives an UDP_INFO message, and it doesn't have a
confirmed UDP tunnel with the originator node, it will update its
records with the new address for that node, so that it always has the
best possible guess as to how to reach that node. This applies to the
destination node of course, but also to any intermediate nodes, because
there's no reason they should pass on the free intel, and because it
results in nice behavior in the presence of relay chains (multiple nodes
in a path all trying to reach the same destination).
If, on the other hand, the node does have a confirmed UDP tunnel, it
will ignore the address information contained in the message.
In all cases, if the node that receives the message is not the
destination node specified in the message, it will forward the message
but not before overriding the address information with the one from its
own records. If the node has a confirmed UDP tunnel, that means the
message is updated with the address of the confirmed tunnel; if not,
the message simply reflects the records of the intermediate node, which
just happen to be the contents of the UDP_INFO message it just got, so
it's simply forwarded with no modification.
This is similar to the way ANS_KEY messages are currently
overloaded to provide UDP address information, with two differences:
- UDP_INFO messages are sent way more often than ANS_KEY messages,
thereby keeping the address information fresh. Previously, if the UDP
situation were to change after the ANS_KEY message was sent, the
sender would virtually never get the updated information.
- Once a node puts address information in an ANS_KEY message, it is
never changed again as the message travels through the metagraph; in
contrast, UDP_INFO messages behave the opposite way, as they get
rewritten every time they travel through a node with a confirmed UDP
tunnel. The latter behavior seems more appropriate because UDP tunnel
information becomes more relevant as it moves closer to the
destination node. The ANS_KEY behavior is not satisfactory in some
cases such as multi-layered graphs where the first hop is located
before a NAT.
Ultimately, the rationale behind this whole process is to improve UDP
hole punching capabilities when port translation is in effect, and more
generally, to make tinc more reliable in (very) hostile network
conditions (such as multi-layered NAT).
2015-01-03 17:46:33 +00:00
/* The packet is supposed to come from the originator or its static relay
( i . e . with no dynamic relays in between ) .
If it did not , " help " the static relay by sending it UDP info .
Note that we only do this if we ' re the destination or the static relay ;
otherwise every hop would initiate its own UDP info message , resulting in elevated chatter . */
if ( n ! = from - > via & & to - > via = = myself )
send_udp_info ( myself , from ) ;
/* If we're not the final recipient, relay the packet. */
2014-12-07 23:58:09 +00:00
if ( to ! = myself ) {
2015-05-18 19:48:45 +00:00
send_sptps_data ( to , from , 0 , DATA ( & pkt ) , pkt . len ) ;
2015-05-10 17:37:30 +00:00
try_tx_sptps ( to , true ) ;
2014-12-07 23:58:09 +00:00
return ;
}
} else {
direct = true ;
from = n ;
}
if ( ! receive_udppacket ( from , & pkt ) )
2014-09-27 17:13:33 +00:00
return ;
2012-02-18 10:48:21 +00:00
2014-09-27 17:13:33 +00:00
n - > sock = ls - listen_socket ;
2014-12-07 23:58:09 +00:00
if ( direct & & sockaddrcmp ( & addr , & n - > address ) )
update_node_udp ( n , & addr ) ;
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
/* If the packet went through a relay, help the sender find the appropriate MTU
through the relay path . */
if ( ! direct )
send_mtu_info ( myself , n , MTU ) ;
2002-02-18 16:25:19 +00:00
}
2007-02-27 01:57:01 +00:00
2012-11-29 11:28:23 +00:00
void handle_device_data ( void * data , int flags ) {
2007-02-27 01:57:01 +00:00
vpn_packet_t packet ;
2014-12-24 21:23:24 +00:00
packet . offset = DEFAULT_PACKET_OFFSET ;
2011-05-29 20:14:35 +00:00
packet . priority = 0 ;
2012-02-22 13:23:59 +00:00
if ( devops . read ( & packet ) ) {
2011-05-14 22:42:29 +00:00
myself - > in_packets + + ;
myself - > in_bytes + = packet . len ;
2007-02-27 01:57:01 +00:00
route ( myself , & packet ) ;
2011-05-14 22:42:29 +00:00
}
2007-02-27 01:57:01 +00:00
}