Segfaults on connection loss

[zorun]

On Thu, Jun 26, 2014 at 08:33:01PM +0200, Guus Sliepen wrote:
> On Wed, Jun 25, 2014 at 08:40:08AM +0200, zorun wrote:
> 
> > I have been able to trigger this segfault reliably, with Tinc 1.0.24:
> > 
> > 0/ setup your local Tinc node to connect to a remote dual-stacked Tinc
> >    node (that is, the remote node has both a A and a AAAA record)
> > 
> > 1/ run Tinc in debug mode, "tincd -n NETNAME -D -d 3"
> > 
> > 2/ wait until Tinc establishes a connection with the remote server
> >    (lots of "Got PACKET from REMOTE (XX.XX.XX.XX port 656)" messages)
> > 
> > 3/ apply an insane amount of delay on your physical interface: "tc
> >    qdisc del dev eth0 root netem delay 10s"
> > 
> > 4/ wait for Tinc to timeout on a ping.  It will then try to reconnect,
> >    and crash:
> 
> I tried to reproduce it, but I do not get a crash. Running it in
> valgrind doesn't produce any errors either. One difference I observe
> with your log:
> 
> > REMOTE (XX.XX.XX.XX port 656) didn't respond to PING in 5 seconds
> > Closing connection with REMOTE (XX.XX.XX.XX port 656)
> > Sending DEL_EDGE to everyone (BROADCAST)
> > UDP address of REMOTE cleared
> > UDP address of OTHER_SERVER1 cleared
> > UDP address of OTHER_SERVER2 cleared
> > UDP address of OTHER_SERVER3 cleared
> > UDP address of OTHER_SERVER4 cleared
> > Sending DEL_EDGE to everyone (BROADCAST)
> > Trying to connect to REMOTE (2001:db8::1 port 656)
> > Connected to REMOTE (2001:db8::1 port 656)
> > Sending ID to REMOTE (2001:db8::1 port 656)
> > Timeout from REMOTE (2001:db8::1 port 656) during authentication
> 
> I wonder how you get to this point with the tc qdisc command, because if
> I do that then it never gets to the point where it makes a connection to
> the other side, because the SYN packets are also delayed 10 seconds. So
> I get:
> 
> Trying to connect to REMOTE (2606:2800:220:6d:26bf:1447:1097:aa7 port 655)
> Connected to REMOTE (2606:2800:220:6d:26bf:1447:1097:aa7 port 655)
> Sending ID to REMOTE (2606:2800:220:6d:26bf:1447:1097:aa7 port 655)
> Timeout from REMOTE (2606:2800:220:6d:26bf:1447:1097:aa7 port 655) during authentication

Isn't that the same output?  Didn't you mean that you *don't* see the
"Connected to REMOTE" part?

But you are right, I forgot to mention I was using a SOCKS5 proxy on
localhost, sorry (I have even removed that from the log, it seems :/).
It makes sense: the TCP connection is established immediately with the
proxy on localhost, since it is not affected by the delaying qdisc.

You can try this:

- ssh -D 4242 -N remote-host
- "Proxy = socks5 localhost 4242" in tinc.conf

Or even a simple SSH tunnel, the result is the same.  Assuming your
ssh client will listen on ::1 and your OS doesn't use IPV6_V6ONLY by
default:

- "ssh -N -L 6565:localhost:655 remote-host"
- hardcode the remote address to both "::1 6565 and "127.0.0.1 6565"
  in the host file

> Another difference is that you have 4 other nodes connected to the VPN,
> what happens if those are not running when you do this test?

I can test that, yes.