From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 12:33:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E052A1065676 for ; Sun, 25 Apr 2010 12:33:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 698F18FC22 for ; Sun, 25 Apr 2010 12:33:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O611E-0001uX-V9 for freebsd-current@freebsd.org; Sun, 25 Apr 2010 14:33:05 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Apr 2010 14:33:04 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Apr 2010 14:33:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org connect(): No such file or directory From: Marcin Cieslak Date: Sun, 25 Apr 2010 12:32:51 +0000 (UTC) Organization: http://saper.info Lines: 63 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info X-Face: "MPx|KfVwz7Gg!ayb)rH,hKiCBJXvLY7t+%r1s0Uiw; (%xWn-C-H38.2Oa4JL|4Cx}a"V ~a pL4%i"s20r0%z0yZew?2><1ZfOFF27cPqcAKp?wG+-c&%BgXeJVm[lylYKH?j User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Sun, 25 Apr 2010 13:16:35 +0000 Subject: State of tun(4) in -CURRENT? No buffer space available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 12:33:10 -0000 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? --Marcin