tinc/src/protocol_misc.c

381 lines
12 KiB
C
Raw Normal View History

2002-02-11 10:05:58 +00:00
/*
protocol_misc.c -- handle the meta-protocol, miscellaneous functions
Copyright (C) 1999-2005 Ivo Timmermans,
2013-08-13 18:38:57 +00:00
2000-2013 Guus Sliepen <guus@tinc-vpn.org>
2002-02-11 10:05:58 +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.
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-11 10:05:58 +00:00
*/
#include "system.h"
2002-02-11 10:05:58 +00:00
#include "conf.h"
#include "connection.h"
#include "logger.h"
#include "meta.h"
2002-02-11 10:05:58 +00:00
#include "net.h"
#include "netutl.h"
#include "protocol.h"
#include "utils.h"
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
#include "xalloc.h"
2002-02-11 10:05:58 +00:00
int maxoutbufsize = 0;
int mtu_info_interval = 5;
int udp_info_interval = 5;
2002-02-11 10:05:58 +00:00
/* Status and error notification routines */
bool send_status(connection_t *c, int statusno, const char *statusstring) {
2002-09-09 21:25:28 +00:00
if(!statusstring)
statusstring = "Status";
2002-09-09 21:25:28 +00:00
return send_request(c, "%d %d %s", STATUS, statusno, statusstring);
2002-02-11 10:05:58 +00:00
}
bool status_h(connection_t *c, const char *request) {
2002-09-09 21:25:28 +00:00
int statusno;
char statusstring[MAX_STRING_SIZE];
if(sscanf(request, "%*d %d " MAX_STRING, &statusno, statusstring) != 2) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "STATUS",
2002-09-09 21:25:28 +00:00
c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
logger(DEBUG_STATUS, LOG_NOTICE, "Status message from %s (%s): %d: %s",
c->name, c->hostname, statusno, statusstring);
2002-09-09 21:25:28 +00:00
2003-07-22 20:55:21 +00:00
return true;
2002-02-11 10:05:58 +00:00
}
bool send_error(connection_t *c, int err, const char *errstring) {
2002-09-09 21:25:28 +00:00
if(!errstring)
errstring = "Error";
2002-09-09 21:25:28 +00:00
return send_request(c, "%d %d %s", ERROR, err, errstring);
2002-02-11 10:05:58 +00:00
}
bool error_h(connection_t *c, const char *request) {
2002-09-09 21:25:28 +00:00
int err;
char errorstring[MAX_STRING_SIZE];
if(sscanf(request, "%*d %d " MAX_STRING, &err, errorstring) != 2) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "ERROR",
2002-09-09 21:25:28 +00:00
c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
logger(DEBUG_ERROR, LOG_NOTICE, "Error message from %s (%s): %d: %s",
c->name, c->hostname, err, errorstring);
2002-09-09 21:25:28 +00:00
return false;
2002-02-11 10:05:58 +00:00
}
bool send_termreq(connection_t *c) {
2002-09-09 21:25:28 +00:00
return send_request(c, "%d", TERMREQ);
2002-02-11 10:05:58 +00:00
}
bool termreq_h(connection_t *c, const char *request) {
return false;
2002-02-11 10:05:58 +00:00
}
bool send_ping(connection_t *c) {
2003-07-22 20:55:21 +00:00
c->status.pinged = true;
c->last_ping_time = now.tv_sec;
2002-09-09 21:25:28 +00:00
return send_request(c, "%d", PING);
2002-02-11 10:05:58 +00:00
}
bool ping_h(connection_t *c, const char *request) {
2002-09-09 21:25:28 +00:00
return send_pong(c);
2002-02-11 10:05:58 +00:00
}
bool send_pong(connection_t *c) {
2002-09-09 21:25:28 +00:00
return send_request(c, "%d", PONG);
2002-02-11 10:05:58 +00:00
}
bool pong_h(connection_t *c, const char *request) {
2003-07-22 20:55:21 +00:00
c->status.pinged = false;
2002-09-09 21:25:28 +00:00
/* Succesful connection, reset timeout if this is an outgoing connection. */
if(c->outgoing) {
2002-09-09 21:25:28 +00:00
c->outgoing->timeout = 0;
c->outgoing->cfg = NULL;
if(c->outgoing->ai)
freeaddrinfo(c->outgoing->ai);
c->outgoing->ai = NULL;
c->outgoing->aip = NULL;
}
2002-09-09 21:25:28 +00:00
2003-07-22 20:55:21 +00:00
return true;
2002-02-11 10:05:58 +00:00
}
/* Sending and receiving packets via TCP */
bool send_tcppacket(connection_t *c, const vpn_packet_t *packet) {
/* If there already is a lot of data in the outbuf buffer, discard this packet.
2012-10-10 15:17:49 +00:00
We use a very simple Random Early Drop algorithm. */
if(2.0 * c->outbuf.len / (float)maxoutbufsize - 1 > (float)rand()/(float)RAND_MAX)
return true;
2002-09-09 21:25:28 +00:00
2003-07-22 20:55:21 +00:00
if(!send_request(c, "%d %hd", PACKET, packet->len))
return false;
2002-09-09 21:25:28 +00:00
return send_meta(c, (char *)DATA(packet), packet->len);
2002-02-11 10:05:58 +00:00
}
bool tcppacket_h(connection_t *c, const char *request) {
2002-09-09 21:25:28 +00:00
short int len;
if(sscanf(request, "%*d %hd", &len) != 1) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "PACKET", c->name,
2002-09-09 21:25:28 +00:00
c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
/* Set reqlen to len, this will tell receive_meta() that a tcppacket is coming. */
c->tcplen = len;
2003-07-22 20:55:21 +00:00
return true;
2002-02-11 10:05:58 +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
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 send_sptps_tcppacket(connection_t *c, const char* packet, int len) {
/* If there already is a lot of data in the outbuf buffer, discard this packet.
We use a very simple Random Early Drop algorithm. */
if(2.0 * c->outbuf.len / (float)maxoutbufsize - 1 > (float)rand()/(float)RAND_MAX)
return true;
if(!send_request(c, "%d %hd", SPTPS_PACKET, len))
return false;
send_meta_raw(c, packet, len);
return true;
}
bool sptps_tcppacket_h(connection_t *c, const char* request) {
short int len;
if(sscanf(request, "%*d %hd", &len) != 1) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "SPTPS_PACKET", c->name,
c->hostname);
return false;
}
/* Set sptpslen to len, this will tell receive_meta() that a SPTPS packet is coming. */
c->sptpslen = len;
return true;
}
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
/* Transmitting UDP information */
bool send_udp_info(node_t *from, node_t *to) {
/* If there's a static relay in the path, there's no point in sending the message
farther than the static relay. */
to = (to->via == myself) ? to->nexthop : to->via;
/* Skip cases where sending UDP info messages doesn't make sense.
This is done here in order to avoid repeating the same logic in multiple callsites. */
if(to == myself)
return true;
if(!to->status.reachable)
return true;
if(from == myself) {
if(to->connection)
return true;
struct timeval elapsed;
timersub(&now, &to->udp_info_sent, &elapsed);
if(elapsed.tv_sec < udp_info_interval)
return true;
}
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
if((myself->options | from->options | to->options) & OPTION_TCPONLY)
return true;
if((to->nexthop->options >> 24) < 5)
return true;
char *from_address, *from_port;
/* If we're the originator, the address we use is irrelevant
because the first intermediate node will ignore it.
We use our local address as it somewhat makes sense
and it's simpler than introducing an encoding for "null" addresses anyway. */
sockaddr2str((from != myself) ? &from->address : &to->nexthop->connection->edge->local_address, &from_address, &from_port);
bool x = send_request(to->nexthop->connection, "%d %s %s %s %s", UDP_INFO, from->name, to->name, from_address, from_port);
free(from_address);
free(from_port);
if(from == myself)
to->udp_info_sent = now;
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
return x;
}
bool udp_info_h(connection_t *c, const char* request) {
char from_name[MAX_STRING_SIZE];
char to_name[MAX_STRING_SIZE];
char from_address[MAX_STRING_SIZE];
char from_port[MAX_STRING_SIZE];
if(sscanf(request, "%*d "MAX_STRING" "MAX_STRING" "MAX_STRING" "MAX_STRING, from_name, to_name, from_address, from_port) != 4) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "UDP_INFO", c->name, c->hostname);
return false;
}
if(!check_id(from_name) || !check_id(to_name)) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s): %s", "UDP_INFO", c->name, c->hostname, "invalid name");
return false;
}
node_t *from = lookup_node(from_name);
if(!from) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got %s from %s (%s) origin %s which does not exist in our connection list", "UDP_INFO", c->name, c->hostname, from_name);
return true;
}
if(from != from->via) {
/* Not supposed to happen, as it means the message wandered past a static relay */
logger(DEBUG_PROTOCOL, LOG_WARNING, "Got UDP info message from %s (%s) which we can't reach directly", from->name, from->hostname);
return true;
}
/* If we have a direct edge to "from", we are in a better position
to guess its address than it is itself. */
if(!from->connection && !from->status.udp_confirmed) {
sockaddr_t from_addr = str2sockaddr(from_address, from_port);
if(sockaddrcmp(&from_addr, &from->address))
update_node_udp(from, &from_addr);
}
node_t *to = lookup_node(to_name);
if(!to) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got %s from %s (%s) destination %s which does not exist in our connection list", "UDP_INFO", c->name, c->hostname, to_name);
return true;
}
/* Send our own data (which could be what we just received) up the chain. */
return send_udp_info(from, to);
}
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
/* Transmitting MTU information */
bool send_mtu_info(node_t *from, node_t *to, int mtu) {
/* Skip cases where sending MTU info messages doesn't make sense.
This is done here in order to avoid repeating the same logic in multiple callsites. */
if(to == myself)
return true;
if(!to->status.reachable)
return true;
if(from == myself) {
if(to->connection)
return true;
struct timeval elapsed;
timersub(&now, &to->mtu_info_sent, &elapsed);
if(elapsed.tv_sec < mtu_info_interval)
return true;
}
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((to->nexthop->options >> 24) < 6)
return true;
/* We will send the passed-in MTU value, unless we believe ours is better. */
node_t *via = (from->via == myself) ? from->nexthop : from->via;
if(from->minmtu == from->maxmtu && from->via == myself) {
/* We have a direct measurement. Override the value entirely.
Note that we only do that if we are sitting as a static relay in the path;
otherwise, we can't guarantee packets will flow through us, and increasing
MTU could therefore end up being too optimistic. */
mtu = from->minmtu;
} else if(via->minmtu == via->maxmtu) {
/* Static relay. Ensure packets will make it through the entire relay path. */
mtu = MIN(mtu, via->minmtu);
} else if(via->nexthop->minmtu == via->nexthop->maxmtu) {
/* Dynamic relay. Ensure packets will make it through the entire relay path. */
mtu = MIN(mtu, via->nexthop->minmtu);
}
if(from == myself)
to->mtu_info_sent = now;
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 none of the conditions above match in the steady state, it means we're using TCP,
so the MTU is irrelevant. That said, it is still important to honor the MTU that was passed in,
because other parts of the relay path might be able to use UDP, which means they care about the MTU. */
return send_request(to->nexthop->connection, "%d %s %s %d", MTU_INFO, from->name, to->name, mtu);
}
bool mtu_info_h(connection_t *c, const char* request) {
char from_name[MAX_STRING_SIZE];
char to_name[MAX_STRING_SIZE];
int mtu;
if(sscanf(request, "%*d "MAX_STRING" "MAX_STRING" %d", from_name, to_name, &mtu) != 3) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s)", "MTU_INFO", c->name, c->hostname);
return false;
}
if(mtu < 512) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s): %s", "MTU_INFO", c->name, c->hostname, "invalid MTU");
return false;
}
mtu = MIN(mtu, MTU);
if(!check_id(from_name) || !check_id(to_name)) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got bad %s from %s (%s): %s", "MTU_INFO", c->name, c->hostname, "invalid name");
return false;
}
node_t *from = lookup_node(from_name);
if(!from) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got %s from %s (%s) origin %s which does not exist in our connection list", "MTU_INFO", c->name, c->hostname, from_name);
return true;
}
/* If we don't know the current MTU for that node, use the one we received.
Even if we're about to make our own measurements, the value we got from downstream nodes should be pretty close
so it's a good idea to use it in the mean time. */
if(from->mtu != mtu && from->minmtu != from->maxmtu) {
logger(DEBUG_TRAFFIC, LOG_INFO, "Using provisional MTU %d for node %s (%s)", mtu, from->name, from->hostname);
from->mtu = mtu;
}
node_t *to = lookup_node(to_name);
if(!to) {
logger(DEBUG_ALWAYS, LOG_ERR, "Got %s from %s (%s) destination %s which does not exist in our connection list", "MTU_INFO", c->name, c->hostname, to_name);
return true;
}
/* Continue passing the MTU value (or a better one if we have it) up the chain. */
return send_mtu_info(from, to, mtu);
}