Observing nasty crashes

Hans Bayle hansb at direct.a2000.nl
Sun Oct 17 14:47:19 CEST 1999


Hi,

This weekend  I changed to faster machines, some very old Ethernet card
and re-tried
Tinc... I stumbled into some nasty bugs.

Packets that are held in the receive queue become corrupted. I observed
lengths (ie, the
len field in the packet structure) that are ok when add_queue() inserts
them in the queue, and way to large lengths or even negative when the
queues get flushed.

Wanna reproduce the problem? Choose 30 seconds for key expiry and 300
seconds
for ping/pong. Do not sent data over the tunnel continuously as with
ping
etc. Just open a telnet session, wait for 5 minutes and type something.
This will almost
certainly trigger a key refresh, which will have a side effect of
flushing the queues.


If the len gets corrupted, the crypting will crash the program (segm
fault).

In general, I think the program needs a checksum to see that it does not
decrypt
corrupted packets. Since it uses UDP, the packets can get corrupted.

After that, I had a look to the add_queue() and flush_queue() funcs.
Need to so some
more work here. flush_queue() will call recv() for more packets that are
in the queue.
It sometimes ends up with calls for packets that do not exist or have
negative lengths.

I do not trust the pointer fiddling in flush_queue(). If it is flushed,
where do q->header
and q->tail point to? Why do the queue elements also have a prev pointer
or where
are these prev pointers used? add_queue() sometimes ends up with a queue
that has only
one packet, with a next pointer pointing to itself.

Letting tincd restart itself will not always work. Its better to run an
outside scheduler that
restarts it when it does not see it anymore in the ps table or when it
detects connection failure. I did this (just let it crash) so that I
also could have the core dumps and see
where it crashes.

Would like to have some more comments in the code. It costs a lot of
time if you
are new to this code and want to find out how it works.

I also was wondering if it is possible to have a stable version and a
developers version.





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



More information about the Tinc mailing list