Possible improvements to LocalDiscovery

Etienne Dechamps etienne at edechamps.fr
Sun Jul 21 18:41:06 CEST 2013


LocalDiscovery works by sending some of the MTU probe packets to the 
broadcast address (255.255.255.255). If the destination node receives 
one of these packets, it will update its UDP cache and reply, thus the 
two nodes will start using their local addresses to communicate.

Now, I see two problems with this approach:

  - In case the two nodes are behind the same NAT and can reach other 
*but* are not on the same broadcast domain, LocalDiscovery won't work. 
This is a typical situation in entreprise/university environments where 
there are often multiple routed private subnets behind the NAT.

  - Contrary to popular belief, sending packets to 255.255.255.255 
doesn't send them on all network interfaces. This is true for Linux and 
Windows[1]. It is hard to predict which interface will be used unless 
one manually looks at the routing table. This can lead to ironic 
situations where tinc tries to send MTU probes on its own VPN. Fixing 
this requires iterating over all interfaces to manually send the probes 
on each one, which is complicated and AFAIK hard to do in a portable way.

To fix these issues, I am suggesting adding functionality to the tinc 
protocol that allows nodes to advertise their own local socket addresses 
(IP and port) to the rest of the graph. Then, instead of sending probes 
to the broadcast address, they would be sent directly to the node's 
local socket address.

IMHO this is an elegant solution that solves both issues above and as an 
added bonus is more friendly to the underlying local network since it 
doesn't use broadcasts. The only situation where it would break is if 
there is a local private NAT between the two local nodes, but this is 
probably an unsolvable problem anyway since we just don't have the 
necessary information to make them reach each other in this case, and 
broadcasts obviously won't get through a NAT.

I guess the local socket information could be added to ADD_EDGE messages 
and stored in edge_t.

Thoughts?

[1] 
http://serverfault.com/questions/72112/how-to-alter-the-global-broadcast-address-255-255-255-255-behavior-on-windows 
(the long discussion in the comments of the second answer are 
particularly interesting)

-- 
Etienne Dechamps


More information about the tinc-devel mailing list