Hello, 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/libc.so.7 (gdb) bt #0 0x2814c797 in recvfrom () from /lib/libc.so.7 #1 0x280a04d1 in recvfrom () from /lib/libthr.so.3 #2 0x0804fee3 in ayiya_writer (arg=0x2822c300) at ../common/ayiya.c:177 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x00000000 in ?? () ayiya.c:177: 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/libc.so.7 (gdb) bt #0 0x28194869 in read () from /lib/libc.so.7 #1 0x280a0576 in read () from /lib/libthr.so.3 #2 0x0804a2fa in tun_reader (arg=0x8055944) at ../common/tun.c:185 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x00000000 in ?? () tun.c:185: 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? --MarcinReceived on Sun Apr 25 2010 - 10:33:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC