TINC 1.0pre2 problem

[Guus Sliepen]

On Sun, 11 Jun 2000, David Summers wrote:

> Hmmm.  One more thing; I noticed here and in your documentation you talk
> about the meta protocol dealing with routing issues.  Does that mean I
> don't have to run a routing protocol on all the connected VPNs that I
> establish?  Does/Would your protocol tell my router A that a route between
> VPN networks B and C has been established?

Tinc 1.0(pre) maintains a list of all tinc daemons that are connected
directly or indirectly with eachother. If a tinc daemon is started and
connects itself to another daemon, then information is passed onto the
complete network of tincds that there is a new one.

If you send a packet to the vpn, tincd reads it from /dev/tap0, and it
determines the destination. It then checks its list of available tinc
daemons to check if there is one that actually serves the subnet that
contains the destination of the packet you just sent. If so, it will send
it DIRECTLY to the corresponding tincd (it does not forward it to the one
specified with ConnectTo, unless ofcourse that is the destination), after
having established a secure connection ofcourse. The receiving tincd will
then act as a gateway for it's subnet.

In effect, tinc acts like a network switch. It currently only handles IPv4
unicast, but future versions will be able to route all packets (based on
MAC addresses), or in a more intelligent way ARP, IPv4 and IPv4 uni, multi
and broadcast.

Met vriendelijke groet,
Guus Sliepen.

-
Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://ftp.nl.linux.org/pub/linux/tinc/