State of tun(4) in -CURRENT? No buffer space available

Marcin Cieslak saper at
Sun Apr 25 12:33:10 UTC 2010


I'm running r203753 (i386) for some time on my IPv6 router. This box
uses net/sixxs-aiccu to establish an IPv6 tunnel to one of the
SixXS POPs. Unfortunately, tun(4) interface exhibits strange behaviour:
after some traffic burst (like opening a ncurses application via ssh)
the interface stops delivering packets. I manually restart the sixxs-aiccu
utility and then it usually works, sometimes for few packets
only, sometimes for minutes or hours. When the link is mostly idle
(e.g. overnight) it stays up.

aiccu (when stopped with SIGQUIT) exhibits three threads,
One of them is the tunnel watchdog thread (probably unreladed).
The other one waits from the data encapsulated via IPv4:

[Switching to thread 1 (Thread 28240ec0 (LWP 100074))]#0  0x2814c797 in recvfrom ()
   from /lib/
(gdb) bt
#0  0x2814c797 in recvfrom () from /lib/
#1  0x280a04d1 in recvfrom () from /lib/
#2  0x0804fee3 in ayiya_writer (arg=0x2822c300) at ../common/ayiya.c:177
#3  0x2809e244 in pthread_getprio () from /lib/
#4  0x00000000 in ?? ()

                n = recvfrom(ayiya_socket->socket, (char *)buf, sizeof
(buf), 0, (struct sockaddr *)&ci, &cl);

Third thread is waiting for packets from tun(4):

[Switching to thread 2 (Thread 28241140 (LWP 100053))]#0  0x28194869 in read ()
   from /lib/
(gdb) bt
#0  0x28194869 in read () from /lib/
#1  0x280a0576 in read () from /lib/
#2  0x0804a2fa in tun_reader (arg=0x8055944) at ../common/tun.c:185
#3  0x2809e244 in pthread_getprio () from /lib/
#4  0x00000000 in ?? ()

                n = read(tun_fd, buf, sizeof(buf));

When the tunnel is "hung" ping6 packets to the other
tunnel end do not go out and after a while:

ping6: sendmsg: No buffer space available

IPv4 connectivity to the tunnel provider is fine,
(ping over IPv4 to the tunnel destination
works fine), I didn't notice any intermittent
connectivity failures that could cause this.
Packets neither come in or come out (checked
looking using some other IPv6 on the network
as I don't control the other end of the tunnel).

I know there has been updates to the tun(4) code since r203753,
but a friend of mine doing the same on his box with
kernel as of April 13th has the same problem. 

Any ideas what's wrong?


More information about the freebsd-current mailing list