tinc version 1.0pre7 hangs

Denny Fox dennyf at microtime.sbwireless.net
Sun May 12 17:19:12 CEST 2002


Hello,

I am running the staticly linked version, tinc version 1.0pre7 (built
Apr  9 2002 14:00:34, protocol 14) on four Debian potato systems. The
kernels are all 2.2.19. The vpn is set up as a star with one hub and
three spokes. The hub and one of the legs share the same ISP and are
on the same subnet. Both the other two legs are on different ISP's.
All the systems are running masquerading firewalls with IP chains, and
are running the tincd.

The vpn seemed to act normally until there needed to be a larger data
transfer required. Then the connection would freeze and require the
process to be killed from the hub. I can also ssh into all the systems
independently from the vpn, so I have another channel to do the
debugging. There were symptoms of getting stuck in many circumstances.
I boiled it down to a simple case that can be repeated at will.

I prepared a series of text files with varying numbers of lines. Each
line is:
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdef
ghijklmn

wc t*.txt
     15      15    1200 t15.txt
     16      16    1280 t16.txt
     17      17    1360 t17.txt
     18      18    1440 t18.txt
     20      20    1600 t20.txt
     30      30    2400 t30.txt
     40      40    3200 t40.txt

>From a client system:
telnet 192.168.200.254		(the hub)
cat t16.txt		(works)
cat t17.txt		(fails, hangs)

I set the debug level to 5 and watched the logs on both sides. The
t16.txt file is 1280 bytes long and produced a udp payload packet of
1378 bytes, this worked. As the udp payload packet size increased, it
failed while doing the cat of the t17.txt file which is 1360 bytes
long, (don't know long the packet itself would have been). This
failure occured on the two clients that has different ISP's than the
hub; one is an ISDN connection, and the other a DSL. This failure did
not occur between the client and the hub that have the same ISP and
Internet subnet.

All nodes were running with no "Compression =" line in their hosts
files. I set "Compression = 5" on all nodes, for all hosts, and that
seems to have worked around the problem. After the compression was set
to 5 the udp payload packet was 1460 bytes long. Now I can cat long
files without getting stuck. With no compression tail -100
/var/log/messages failed, with compression = 5, it works.

So it would seem that there is a problem with no compression and udp
packet length, at least on in some cases.

I hope this helps to isolate the problem.

Thanks,

Denny Fox

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




More information about the Tinc mailing list