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/