Thanks Guus. Appreciate the help. What's the purpose of SUBNET msg? Is it even useful in switch mode?
I tweaked the code to disable SUBNET msg, because I thought they weren't useful when it comes to switch mode. Which caused the UDP connection got blocked apparently. If I re-enable SUBNET msg, the udp connection starts to work fine. I don't see any forwarding traffic any more. On Thu, Oct 12, 2017 at 6:00 AM, <[email protected]> wrote: > Send tinc mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tinc digest..." > > Today's Topics: > > 1. Re: UDP connections on tinc (Guus Sliepen) > > > ---------- Forwarded message ---------- > From: Guus Sliepen <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Wed, 11 Oct 2017 19:20:06 +0200 > Subject: Re: UDP connections on tinc > On Tue, Oct 10, 2017 at 10:48:22AM -0400, Heng Wang wrote: > > > We are using tinc 1.0.24 with switch mode. Some questions regarding to > the > > UDP connections on tinc. > > > > As far as I understand tinc is building meta connections with > "ConnectTo", > > and "ADD_EDGE" packet. With the help of EDGE info two nodes who don't > have > > direct meta connection are able to communicate through direct UDP > > connection. > > Correct. > > > I understand we can dump the meta connection using USR2 signal. However > is > > there a way to know if a direct UDP connection exists between two nodes? > > If you do USR2 you also get a list of nodes. There's quite a lot of > information for each node. Look at the min mtu value, if it is greater > than 0, you have a direct UDP connection to that node. However, UDP > connections are made on-demand, so if you haven't sent anything to that > node yet, it will likely still be 0. > > > UDP connection will fall back to the meta connection(with next-hop..) if > > the direct UDP fails, but what are the possible reasons for its failure? > > It could be a NAT device that doesn't allow UDP hole punching, or a > firewall that blocks tinc's UDP packets. These problems might exist at > either peer, or somewhere inbetween. > > > Currently we have a connection like below: > > > > A-->H > > G-->H > > D-->A > > E-->A > > F-->A > > If we try to send packets directly from G to D, seems the direct UDP > > connection always fails and it is going to path G-->H-->A-->D, however > > somehow it got broadcasted during the process, because I can see that > > message on E and F. Does this even make sense? > > Yes, if it gets broadcast in switch mode, that means that tinc didn't > know which node had the destination address. Just like a real physical > Ethernet switch, if you send packets to a MAC address that it doesn't > know, it will broadcast it on all ports. So it could be that you are > sending a packet to the wrong IP address, or that it's the right IP > address but the node that should have that IP address is misconfigured > somehow, or it could be that that node is offline. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <[email protected]> > > _______________________________________________ > tinc mailing list > [email protected] > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
