2001-10-10 08:49:47 +00:00
|
|
|
/*
|
|
|
|
node.c -- node tree management
|
2013-05-01 15:17:22 +00:00
|
|
|
Copyright (C) 2001-2013 Guus Sliepen <guus@tinc-vpn.org>,
|
2006-04-26 13:52:58 +00:00
|
|
|
2001-2005 Ivo Timmermans
|
2001-10-10 08:49:47 +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.
|
2001-10-10 08:49:47 +00:00
|
|
|
*/
|
|
|
|
|
2003-07-17 15:06:27 +00:00
|
|
|
#include "system.h"
|
2001-10-27 12:13:17 +00:00
|
|
|
|
2009-11-07 22:43:25 +00:00
|
|
|
#include "control_common.h"
|
2012-09-05 11:05:48 +00:00
|
|
|
#include "hash.h"
|
2003-07-06 22:11:37 +00:00
|
|
|
#include "logger.h"
|
2003-07-17 15:06:27 +00:00
|
|
|
#include "net.h"
|
|
|
|
#include "netutl.h"
|
|
|
|
#include "node.h"
|
2012-09-05 11:05:48 +00:00
|
|
|
#include "splay_tree.h"
|
2003-07-17 15:06:27 +00:00
|
|
|
#include "utils.h"
|
|
|
|
#include "xalloc.h"
|
2001-10-27 12:13:17 +00:00
|
|
|
|
2014-12-29 21:57:18 +00:00
|
|
|
#include "ed25519/sha512.h"
|
2014-09-21 17:17:02 +00:00
|
|
|
|
2012-10-10 15:17:49 +00:00
|
|
|
splay_tree_t *node_tree;
|
2014-09-21 17:17:02 +00:00
|
|
|
static splay_tree_t *node_id_tree;
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
static splay_tree_t *node_udp_tree;
|
2014-12-07 21:11:37 +00:00
|
|
|
static hash_t *node_id_cache;
|
2001-10-10 08:49:47 +00:00
|
|
|
|
2001-10-27 13:13:35 +00:00
|
|
|
node_t *myself;
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
static int node_compare(const node_t *a, const node_t *b) {
|
2002-09-09 21:25:28 +00:00
|
|
|
return strcmp(a->name, b->name);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2014-09-21 17:17:02 +00:00
|
|
|
static int node_id_compare(const node_t *a, const node_t *b) {
|
|
|
|
return memcmp(&a->id, &b->id, sizeof(node_id_t));
|
|
|
|
}
|
|
|
|
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
static int node_udp_compare(const node_t *a, const node_t *b) {
|
|
|
|
int result = sockaddrcmp(&a->address, &b->address);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
return (a->name && b->name) ? strcmp(a->name, b->name) : 0;
|
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
void init_nodes(void) {
|
2007-05-18 10:05:26 +00:00
|
|
|
node_tree = splay_alloc_tree((splay_compare_t) node_compare, (splay_action_t) free_node);
|
2014-09-21 17:17:02 +00:00
|
|
|
node_id_tree = splay_alloc_tree((splay_compare_t) node_id_compare, NULL);
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
node_udp_tree = splay_alloc_tree((splay_compare_t) node_udp_compare, NULL);
|
2014-12-07 21:11:37 +00:00
|
|
|
node_id_cache = hash_alloc(0x100, sizeof(node_id_t));
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
void exit_nodes(void) {
|
2014-12-07 21:11:37 +00:00
|
|
|
hash_free(node_id_cache);
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
splay_delete_tree(node_udp_tree);
|
2014-09-21 17:17:02 +00:00
|
|
|
splay_delete_tree(node_id_tree);
|
2007-05-18 10:05:26 +00:00
|
|
|
splay_delete_tree(node_tree);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
node_t *new_node(void) {
|
2013-05-01 15:31:33 +00:00
|
|
|
node_t *n = xzalloc(sizeof *n);
|
2002-09-09 21:25:28 +00:00
|
|
|
|
2013-05-01 15:31:33 +00:00
|
|
|
if(replaywin) n->late = xzalloc(replaywin);
|
2002-09-09 21:25:28 +00:00
|
|
|
n->subnet_tree = new_subnet_tree();
|
|
|
|
n->edge_tree = new_edge_tree();
|
2003-12-20 19:47:53 +00:00
|
|
|
n->mtu = MTU;
|
2003-12-22 11:04:17 +00:00
|
|
|
n->maxmtu = MTU;
|
2002-09-09 21:25:28 +00:00
|
|
|
|
|
|
|
return n;
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
void free_node(node_t *n) {
|
2002-09-09 21:25:28 +00:00
|
|
|
if(n->subnet_tree)
|
|
|
|
free_subnet_tree(n->subnet_tree);
|
|
|
|
|
|
|
|
if(n->edge_tree)
|
|
|
|
free_edge_tree(n->edge_tree);
|
|
|
|
|
2003-08-22 11:18:42 +00:00
|
|
|
sockaddrfree(&n->address);
|
|
|
|
|
2014-12-29 21:57:18 +00:00
|
|
|
#ifndef DISABLE_LEGACY
|
2013-05-01 15:17:22 +00:00
|
|
|
cipher_close(n->incipher);
|
|
|
|
digest_close(n->indigest);
|
|
|
|
cipher_close(n->outcipher);
|
|
|
|
digest_close(n->outdigest);
|
2014-12-29 21:57:18 +00:00
|
|
|
#endif
|
2003-12-22 11:04:17 +00:00
|
|
|
|
2013-05-01 15:17:22 +00:00
|
|
|
ecdsa_free(n->ecdsa);
|
2012-07-30 16:36:59 +00:00
|
|
|
sptps_stop(&n->sptps);
|
2011-07-16 18:21:44 +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
|
|
|
timeout_del(&n->udp_ping_timeout);
|
2012-10-10 15:17:49 +00:00
|
|
|
|
2006-11-11 22:44:15 +00:00
|
|
|
if(n->hostname)
|
|
|
|
free(n->hostname);
|
|
|
|
|
|
|
|
if(n->name)
|
|
|
|
free(n->name);
|
|
|
|
|
2010-11-13 20:36:51 +00:00
|
|
|
if(n->late)
|
|
|
|
free(n->late);
|
|
|
|
|
2002-09-09 21:25:28 +00:00
|
|
|
free(n);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
void node_add(node_t *n) {
|
2014-12-29 21:57:18 +00:00
|
|
|
unsigned char buf[64];
|
|
|
|
sha512(n->name, strlen(n->name),buf);
|
|
|
|
memcpy(&n->id, buf, sizeof n->id);
|
2014-09-21 17:17:02 +00:00
|
|
|
|
2007-05-18 10:05:26 +00:00
|
|
|
splay_insert(node_tree, n);
|
2014-09-21 17:17:02 +00:00
|
|
|
splay_insert(node_id_tree, n);
|
2001-10-27 12:13:17 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
void node_del(node_t *n) {
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
splay_delete(node_udp_tree, n);
|
2014-12-07 21:11:37 +00:00
|
|
|
hash_delete(node_id_cache, &n->id);
|
|
|
|
|
2012-10-07 22:35:38 +00:00
|
|
|
for splay_each(subnet_t, s, n->subnet_tree)
|
2002-09-09 21:25:28 +00:00
|
|
|
subnet_del(n, s);
|
|
|
|
|
2012-10-07 22:35:38 +00:00
|
|
|
for splay_each(edge_t, e, n->edge_tree)
|
2002-09-09 21:25:28 +00:00
|
|
|
edge_del(e);
|
|
|
|
|
2014-09-21 17:17:02 +00:00
|
|
|
splay_delete(node_id_tree, n);
|
2009-09-16 17:55:47 +00:00
|
|
|
splay_delete(node_tree, n);
|
2001-10-27 12:13:17 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
node_t *lookup_node(char *name) {
|
2011-05-28 01:46:39 +00:00
|
|
|
node_t n = {NULL};
|
2003-07-24 12:08:16 +00:00
|
|
|
|
2003-07-30 11:50:45 +00:00
|
|
|
n.name = name;
|
|
|
|
|
2007-05-18 10:05:26 +00:00
|
|
|
return splay_search(node_tree, &n);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2014-09-21 17:17:02 +00:00
|
|
|
node_t *lookup_node_id(const node_id_t *id) {
|
2014-12-07 21:11:37 +00:00
|
|
|
node_t *n = hash_search(node_id_cache, id);
|
|
|
|
if(!n) {
|
|
|
|
node_t tmp = {.id = *id};
|
|
|
|
n = splay_search(node_id_tree, &tmp);
|
|
|
|
if(n)
|
|
|
|
hash_insert(node_id_cache, id, n);
|
|
|
|
}
|
2014-09-21 17:17:02 +00:00
|
|
|
|
2014-12-07 21:11:37 +00:00
|
|
|
return n;
|
2014-09-21 17:17:02 +00:00
|
|
|
}
|
|
|
|
|
2007-05-18 10:00:00 +00:00
|
|
|
node_t *lookup_node_udp(const sockaddr_t *sa) {
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
node_t tmp = {.address = *sa};
|
|
|
|
return splay_search(node_udp_tree, &tmp);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2009-09-24 22:14:03 +00:00
|
|
|
void update_node_udp(node_t *n, const sockaddr_t *sa) {
|
2011-02-18 22:11:43 +00:00
|
|
|
if(n == myself) {
|
2012-02-26 17:37:36 +00:00
|
|
|
logger(DEBUG_ALWAYS, LOG_WARNING, "Trying to update UDP address of myself!");
|
2011-02-18 22:11:43 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
splay_delete(node_udp_tree, n);
|
2012-09-05 11:05:48 +00:00
|
|
|
|
2009-04-02 23:05:23 +00:00
|
|
|
if(sa) {
|
|
|
|
n->address = *sa;
|
2012-11-17 21:14:52 +00:00
|
|
|
n->sock = 0;
|
|
|
|
for(int i = 0; i < listen_sockets; i++) {
|
|
|
|
if(listen_socket[i].sa.sa.sa_family == sa->sa.sa_family) {
|
|
|
|
n->sock = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
Use a splay tree for node UDP addresses in order to avoid collisions.
This commit replaces the node UDP address hash table "cache" with a
full-blown splay tree, aligning it with node_tree (name-indexed) and
node_id_tree (ID-indexed).
I'm doing this for two reasons. The first reason is to make sure we
don't suddenly degrade to O(n) performance when two "hot" nodes end up
in the same hash table bucket (collision).
The second, and most important, reason, has to do with the fact that
the hash table that was being used overrides elements that collide.
Indeed, it turns out that there is one scenario in which the contents of
node_udp_cache has *correctness* implications, not just performance
implications. This has to do with the way handle_incoming_vpn_data() is
implemented.
Assume the following topology:
A <-> B <-> C
Now let's consider the perspective of tincd running on B, and let's
assume the following is true:
- All nodes are using the 1.1 protocol with node IDs and relaying
support.
- Nodes A and C have UDP addresses that hash to the same value.
- Node C "wins" in the node_udp_cache (i.e. it overwrites A in the
cache).
- Node A has a "dynamic" UDP address (i.e. an UDP address that has been
detected dynamically and cannot be deduced from edge addresses).
Then, before this commit, A would be unable to relay packets through B.
This is because handle_incoming_vpn_data() will fall back to
try_harder(), which won't be able to match any edge addresses, doesn't
check the dynamic UDP addresses, and won't be able to match any keys
because this is a relayed packet which is encrypted with C's key, not
B's. As a result, tinc will fail to match the source of the packet and
will drop the packet with a "Received UDP packet from unknown source"
message.
I have seen this happen in the wild; it is actually quite likely to
occur when there are more than a handful of nodes because node_udp_cache
only has 256 buckets, making collisions quite likely. This problem is
quite severe because it can completely prevent all packet communication
between nodes - indeed, if node A tries to initiate some communication
with C, it will use relaying at first, until C responds and helps A
establish direct communication with it (e.g. hole punching). If relaying
is broken, C will not help establish direct communication, and as a
result no packets can make it through at all.
The bug can be reproduced fairly easily by reproducing the topology
above while changing the (hardcoded) node_udp_cache size to 1 to force a
collision. One will quickly observe various issues when trying to make A
talk to C. Setting IndirectData on B will make the issue even more
severe and prevent all communication.
Arguably, another way to fix this problem is to make try_harder()
compare the packet's source address to each node's dynamic UDP
addresses. However, I do not like this solution because if two "hot"
nodes are contending on the same hash bucket, try_harder() will be
called very often and packet routing performance will degrade closer to
O(N) (where N is the total number of nodes in the graph). Using a more
appropriate data structure fixes the bug without introducing this
performance problem.
2015-11-04 19:07:14 +00:00
|
|
|
splay_insert(node_udp_tree, n);
|
2012-09-26 20:20:43 +00:00
|
|
|
free(n->hostname);
|
2009-04-02 23:05:23 +00:00
|
|
|
n->hostname = sockaddr2hostname(&n->address);
|
2012-02-26 17:37:36 +00:00
|
|
|
logger(DEBUG_PROTOCOL, LOG_DEBUG, "UDP address of %s set to %s", n->name, n->hostname);
|
2009-04-02 23:05:23 +00:00
|
|
|
}
|
2014-09-21 14:44:59 +00:00
|
|
|
|
|
|
|
/* invalidate UDP information - note that this is a security feature as well to make sure
|
|
|
|
we can't be tricked into flooding any random address with UDP packets */
|
|
|
|
n->status.udp_confirmed = false;
|
2015-01-11 15:10:58 +00:00
|
|
|
n->maxrecentlen = 0;
|
2014-09-21 14:44:59 +00:00
|
|
|
n->mtuprobes = 0;
|
|
|
|
n->minmtu = 0;
|
|
|
|
n->maxmtu = MTU;
|
2009-04-02 23:05:23 +00:00
|
|
|
}
|
|
|
|
|
2009-11-07 22:43:25 +00:00
|
|
|
bool dump_nodes(connection_t *c) {
|
2014-09-21 17:17:02 +00:00
|
|
|
for splay_each(node_t, n, node_tree) {
|
|
|
|
char id[2 * sizeof n->id + 1];
|
|
|
|
for (size_t c = 0; c < sizeof n->id; ++c)
|
|
|
|
sprintf(id + 2 * c, "%02hhx", n->id.x[c]);
|
|
|
|
id[sizeof id - 1] = 0;
|
|
|
|
send_request(c, "%d %d %s %s %s %d %d %d %d %x %x %s %s %d %hd %hd %hd %ld", CONTROL, REQ_DUMP_NODES,
|
2014-12-29 21:57:18 +00:00
|
|
|
n->name, id, n->hostname ?: "unknown port unknown",
|
|
|
|
#ifdef DISABLE_LEGACY
|
|
|
|
0, 0, 0,
|
|
|
|
#else
|
|
|
|
cipher_get_nid(n->outcipher), digest_get_nid(n->outdigest), (int)digest_length(n->outdigest),
|
|
|
|
#endif
|
|
|
|
n->outcompression, n->options, bitfield_to_int(&n->status, sizeof n->status),
|
|
|
|
n->nexthop ? n->nexthop->name : "-", n->via ? n->via->name ?: "-" : "-", n->distance,
|
|
|
|
n->mtu, n->minmtu, n->maxmtu, (long)n->last_state_change);
|
2014-09-21 17:17:02 +00:00
|
|
|
}
|
2002-09-09 21:25:28 +00:00
|
|
|
|
2009-11-07 22:43:25 +00:00
|
|
|
return send_request(c, "%d %d", CONTROL, REQ_DUMP_NODES);
|
2001-10-10 08:49:47 +00:00
|
|
|
}
|
2011-05-15 09:59:13 +00:00
|
|
|
|
|
|
|
bool dump_traffic(connection_t *c) {
|
2012-10-07 22:35:38 +00:00
|
|
|
for splay_each(node_t, n, node_tree)
|
2011-05-15 09:59:13 +00:00
|
|
|
send_request(c, "%d %d %s %"PRIu64" %"PRIu64" %"PRIu64" %"PRIu64, CONTROL, REQ_DUMP_TRAFFIC,
|
|
|
|
n->name, n->in_packets, n->in_bytes, n->out_packets, n->out_bytes);
|
|
|
|
|
|
|
|
return send_request(c, "%d %d", CONTROL, REQ_DUMP_TRAFFIC);
|
|
|
|
}
|