Packet capture to analysis the tinc connection close

Etienne Dechamps etienne at edechamps.fr
Wed Sep 13 21:02:11 CEST 2017


It seems like that kind of problem could be solved by making sure that tinc
continues PINGing over TCP metaconnections even when an UDP tunnel is
established, to keep the metaconnection alive. In fact I was under the
impression that the 1.1 branch already did that or that I had submitted
some code to do that at some point in the past, but it looks like I maybe
be misremembering things.

On 13 September 2017 at 16:13, Guus Sliepen <guus at tinc-vpn.org> wrote:

> On Fri, Sep 08, 2017 at 06:35:41AM +0800, Bright Zhao wrote:
>
> > And, I ran a constant ping from the tinc client’s IP to the tinc
> server’s IP, it shows, the pings are all successfully back and forth, no
> any packet loss during the connection drop happens, so will this help to
> exclude any NAT/firewall cause the connection drop?
> >
> > And as you saw from the earlier screen shot, when it happens, it drop
> all tinc connections, and those connections are for different direction of
> tinc servesr, and the packet capture is just show one of the connections.
> >
> > I do realize the connection drop in the picture happens 10 mins, but the
> tinc client is direct connect to SP with public routable IP, without any
> firewall/NAT. Just trying to know if there’s any other reason might cause
> this?
> >
> > And BTW, this type of connection drop is not regularly with pattern,
> sometimes it happens, sometimes it doesn’t.
>
> Tinc itself wouldn't cause these kind of reconnections. It clearly sees
> a timeout, which means it didn't receive a response to its PING packets in
> time. Unfortunately, there are two classes of devices that are not
> uncommon that could cause this to happen: consumer ADSL/cable modems
> tend to have very short timeouts on connections or NAT mappings, and
> some providers just randomly drop long-lived connections for various
> reasons (mainly because they think you should only browse webpages,
> which only requires short-lived TCP connections, which is also easy to
> analyze, and they want to discourage VPNs, VoIP et cetera).
>
> But just to be sure, just set up a TCP connection between the two nodes
> using netcat or socket for example, send something over that connection
> every minute, and see how long it lasts.
>
> You can also try to reduce PingInterval to, say, 30, and see if that
> improves anything.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170913/fdc38c29/attachment-0001.html>


More information about the tinc mailing list