From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 08:11:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3603B7D7 for ; Sun, 7 Apr 2013 08:11:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id F0E7D1CF1 for ; Sun, 7 Apr 2013 08:11:08 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:4c8a:eb64:d147:30a4]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 74A734AC57 for ; Sun, 7 Apr 2013 12:11:03 +0400 (MSK) Date: Sun, 7 Apr 2013 12:11:02 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <563362676.20130407121102@serebryakov.spb.ru> To: freebsd-net@freebsd.org Subject: BSNMPD: several (cosmetic?) problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 08:11:09 -0000 Hello, Freebsd-net. (1) I have a lot of "could not encode error response" in /var/log/messages after change of hardware. It looks like, every request from mrtg for "unexistent" interface leads to this message. I'll reconfigure mrtg, of course, but it is annoying. (2) With wlan plugin daemon complains "unknown regdomain (0x8a)", and I have "regdomain ROW country DE" on my WiFi card. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 09:15:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 694E228A; Sun, 7 Apr 2013 09:15:23 +0000 (UTC) (envelope-from cs@innolan.dk) Received: from serv.innomanslan.tf (0126800067.1.fullrate.dk [95.166.204.165]) by mx1.freebsd.org (Postfix) with ESMTP id DE3DA1F3F; Sun, 7 Apr 2013 09:15:22 +0000 (UTC) Received: from [192.168.44.228] (192.168.44.228) by serv.innomanslan.tf (Axigen) with ESMTP id 2F4E25; Sun, 7 Apr 2013 11:15:14 +0200 Message-ID: <51613922.6090408@innolan.dk> Date: Sun, 07 Apr 2013 11:15:14 +0200 From: Carsten Sonne Larsen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130324 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-jail@freebsd.org Subject: Re: Problems with network on host with jail. References: <65534.1365280473.6122751498602086400@ffe16.ukr.net> In-Reply-To: <65534.1365280473.6122751498602086400@ffe16.ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 09:15:23 -0000 Hi Vitaliy, One way could be to install arping from /ports/net/arping and see if you can reach the NIC on the border router from the LAN zone. Cheers, -- On 04/06/2013 22:34, wishmaster wrote: > Hi. > Since I setuped Jail for www stuff in server there are network problems. Router has 3 NIC's in bridge with aliases. > > cloned_interfaces="bridge0" > ifconfig_bridge0="addm rl1 addm rl2 addm rl3 up" > ifconfig_rl1="up -wol" > ifconfig_rl2="up -wol" > ifconfig_rl3="up -wol" > ifconfig_bridge0_alias0="inet 10.11.1.1 netmask 255.255.255.0" > ifconfig_bridge0_alias1="inet 10.12.1.1 netmask 255.255.255.0" > ifconfig_bridge0_alias2="inet 10.13.1.1 netmask 255.255.255.0" > ifconfig_bridge0_alias3="inet 10.14.1.1 netmask 255.255.255.192" > ifconfig_bridge0_alias4="inet 10.15.1.1 netmask 255.255.255.0" > > Also I use PF for filtering traffic. There are a lot of rules. In two words: it is unable to reach any host in LAN and also any IP addresses on router, allowed access to Internet only. In other words Jail in original DMZ zone with IP 10.15.1.1. > > In random time (about one incident per-(2|3)days) the strange situations is occur: I am unable to ping/ftp/http from jail or from LAN any host in Internet. From/to router - it's ok. Restarting PF and jail seems to have no effect, only router's reboot. > > From pftop I see traffic, coming from jail or LAN but in the other way - no. > > Anybody can give me some help in debugging this situation and figure out the problem? > > OS: FreeBSD 9.1-STABLE #0: Fri Feb 22 20:51:16 EET 2013 i386 > > Cheers, > Vitaliy > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 12:23:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC03E348 for ; Sun, 7 Apr 2013 12:23:28 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 33BB59E9 for ; Sun, 7 Apr 2013 12:23:28 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r37CNK3n032093; Sun, 7 Apr 2013 14:23:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r37CNJgt032092; Sun, 7 Apr 2013 14:23:19 +0200 (CEST) (envelope-from marius) Date: Sun, 7 Apr 2013 14:23:19 +0200 From: Marius Strobl To: Joe Holden Subject: Re: rarpd Message-ID: <20130407122319.GA31547@alchemy.franken.de> References: <515F6734.2040302@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515F6734.2040302@rewt.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:23:28 -0000 On Sat, Apr 06, 2013 at 01:07:16AM +0100, Joe Holden wrote: > Hi guys, > > I'm trying to make rarpd behave, but it doesn't seem to want to listen > on vlan interfaces, or at least not mine: Looks like you are using a FreeBSD version that misses the following change: http://svnweb.freebsd.org/base?view=revision&revision=238282 Marius From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 14:10:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C99B6A44 for ; Sun, 7 Apr 2013 14:10:24 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 97A63E69 for ; Sun, 7 Apr 2013 14:10:23 +0000 (UTC) Received: from [IPv6:2001:b70:201:300::397] (unknown [IPv6:2001:b70:201:300::397]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZkGqr1lbHzCH; Sun, 7 Apr 2013 15:10:16 +0100 (BST) Message-ID: <51617E3D.4060804@rewt.org.uk> Date: Sun, 07 Apr 2013 15:10:05 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marius Strobl Subject: Re: rarpd References: <515F6734.2040302@rewt.org.uk> <20130407122319.GA31547@alchemy.franken.de> In-Reply-To: <20130407122319.GA31547@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:10:24 -0000 Marius Strobl wrote: > On Sat, Apr 06, 2013 at 01:07:16AM +0100, Joe Holden wrote: >> Hi guys, >> >> I'm trying to make rarpd behave, but it doesn't seem to want to listen >> on vlan interfaces, or at least not mine: > > Looks like you are using a FreeBSD version that misses the following > change: > http://svnweb.freebsd.org/base?view=revision&revision=238282 > > Marius > Someone must have forgotten to MFC it then, it's not in 9.1-R From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 15:25:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AE50687 for ; Sun, 7 Apr 2013 15:25:09 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BD59914B for ; Sun, 7 Apr 2013 15:25:08 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r37FP78j032674; Sun, 7 Apr 2013 17:25:07 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r37FP6QH032673; Sun, 7 Apr 2013 17:25:06 +0200 (CEST) (envelope-from marius) Date: Sun, 7 Apr 2013 17:25:06 +0200 From: Marius Strobl To: Joe Holden Subject: Re: rarpd Message-ID: <20130407152506.GK33031@alchemy.franken.de> References: <515F6734.2040302@rewt.org.uk> <20130407122319.GA31547@alchemy.franken.de> <51617E3D.4060804@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51617E3D.4060804@rewt.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:25:09 -0000 On Sun, Apr 07, 2013 at 03:10:05PM +0100, Joe Holden wrote: > Marius Strobl wrote: > > On Sat, Apr 06, 2013 at 01:07:16AM +0100, Joe Holden wrote: > >> Hi guys, > >> > >> I'm trying to make rarpd behave, but it doesn't seem to want to listen > >> on vlan interfaces, or at least not mine: > > > > Looks like you are using a FreeBSD version that misses the following > > change: > > http://svnweb.freebsd.org/base?view=revision&revision=238282 > > > Someone must have forgotten to MFC it then, it's not in 9.1-R It has been MFC'ed post 9.1-R: http://svnweb.freebsd.org/base?view=revision&revision=245076 Marius From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 20:27:09 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13D7E8AF; Sun, 7 Apr 2013 20:27:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E0579EAB; Sun, 7 Apr 2013 20:27:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r37KR8M1085872; Sun, 7 Apr 2013 20:27:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r37KR88B085871; Sun, 7 Apr 2013 20:27:08 GMT (envelope-from linimon) Date: Sun, 7 Apr 2013 20:27:08 GMT Message-Id: <201304072027.r37KR88B085871@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177696: [patch] [net] Removing an unavailable sysctl from manpage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 20:27:09 -0000 Synopsis: [patch] [net] Removing an unavailable sysctl from manpage Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 7 20:27:02 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177696 From owner-freebsd-net@FreeBSD.ORG Sun Apr 7 21:28:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 418D9445 for ; Sun, 7 Apr 2013 21:28:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EA34BD7 for ; Sun, 7 Apr 2013 21:28:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAJbjYVGDaFvO/2dsb2JhbABRFoMmgyq9eoEYdIIfAQEBAwEBAQEgBCcgCxkCDgoCAg0ZAiMGAQkmBggHBAEcBIdhAwkGDJBKmwSHaQ2JXYEjiy2BERB+ATMHgi6BEwOKfIk5XoFhgSGIVYF9hRuDJyAygQU1 X-IronPort-AV: E=Sophos;i="4.87,427,1363147200"; d="scan'208";a="24822315" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Apr 2013 17:28:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1796FB3F4F; Sun, 7 Apr 2013 17:28:49 -0400 (EDT) Date: Sun, 7 Apr 2013 17:28:49 -0400 (EDT) From: Rick Macklem To: Juan Mojica Message-ID: <889005941.599737.1365370129081.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic in tcp_do_segment() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: FreeBSD Net , Matt Miller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 21:28:56 -0000 Juan Mojica wrote: > Agree with Matt. >=20 > Whenever there is an UNLOCK/LOCK like is present in soclose(), there > is a window to allow something through.=C2=A0 Unsetting SO_ACCEPTCONN was > put in place because the LOCK/UNLOCK in soclose let a new socket to be > added to the so_incomp list causing a different ASSERT to be hit - and > memory to be leaked. >=20 > As far as I can tell, because of the upcall performed in soabort(), we > can't just hold the ACCEPT lock all the way through the close. >=20 >=20 > The simplest thing to do in this case seemed to be to just drop the > TCP segment - the connection is being closed anyway.=C2=A0 Or like Matt > said, having someone look at the lock logic and see if there is > something there that can be exploited to prevent this would also help. >=20 >=20 > -Juan >=20 >=20 >=20 >=20 > On Fri, Apr 5, 2013 at 7:09 AM, Matt Miller < matt@matthewjmiller.net > > wrote: >=20 >=20 >=20 >=20 > Hey Rick, >=20 > I believe Juan and I have root caused this crash recently.=C2=A0 The > t_state =3D 0x1, TCPS_LISTEN, in the link provided at the time of the > assertion. >=20 > In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set > on the socket and we should never enter tcp_do_segment() for this > state.=C2=A0 I think if you look in your corefile, you'll see the socket > *doesn't* have this flag set in your case. >=20 Thanks guys. I had missed the *tp near the end and mistakenly was thinking it was the client socket. This sounds like a good explanation to me. Hopefully, one of the tcp stack guys will pick this up and commit a patch, rick. >=20 > 1043=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > 1044=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * When the soc= ket is accepting connections (the INPCB is > in LISTEN > 1045=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * state) we lo= ok into the SYN cache if this is a new > connection > 1046=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * attempt or t= he completion of a previous one.=C2=A0 Because > listen > 1047=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * sockets are = never in TCPS_ESTABLISHED, the V_tcbinfo > lock will be > 1048=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * held in this= case. > 1049=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ > 1050=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (so->so_options &= SO_ACCEPTCONN) { > 1051=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 struct in_conninfo inc; > 1052 > 1053=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 KASSERT(tp->t_state =3D=3D TCPS_LISTEN, ("%s: s= o > accepting but " > 1054=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "tp not listening", __f= unc__)); > ... > 1356=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 syncache_add(&inc, &to, th, inp, &so, m, NULL, > NULL); > 1357=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > 1358=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Entry added to syncache and mbuf consum= ed. > 1359=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Everything already unlocked by syncache= _add(). > 1360=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ > 1361=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > 1362=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 return; > 1363=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > ... > 1384=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > 1385=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Segment belo= ngs to a connection in SYN_SENT, > ESTABLISHED or later > 1386=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * state.=C2=A0= tcp_do_segment() always consumes the mbuf > chain, unlocks > 1387=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * the inpcb, a= nd unlocks pcbinfo. > 1388=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ > 1389=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tcp_do_segment(m, th= , so, tp, drop_hdrlen, tlen, iptos, > ti_locked); >=20 >=20 > I think this has to do with this patch in soclose() where > SO_ACCEPTCONN is being turned off in soclose().=C2=A0 I suspect if you lo= ok > at the other threads in your corefile, you'll see one at this point in > soclose() operating on the same socket as the one in the > tcp_do_segment() thread. >=20 >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D243627 >=20 > =C2=A0817=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* > =C2=A0818=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Prevent new additions to the acce= pt queues due > =C2=A0819=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * to ACCEPT_LOCK races while we are= draining > them. > =C2=A0820=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ > =C2=A0821=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so->so_options &=3D ~SO_ACCEPTCONN; > =C2=A0822=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 while ((sp =3D TAILQ_FIRST(&so->so_incomp= )) !=3D > NULL) { > =C2=A0823=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 TAILQ_REMOVE(&so->so_incomp, sp, > so_list); > =C2=A0824=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 so->so_incqlen--; > =C2=A0825=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 sp->so_qstate &=3D ~SQ_INCOMP; > =C2=A0826=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 sp->so_head =3D NULL; > =C2=A0827=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ACCEPT_UNLOCK(); > =C2=A0828=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 soabort(sp); > =C2=A0829=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ACCEPT_LOCK(); > =C2=A0830=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >=20 >=20 > Juan had evaluated this code path and it seemed safe to just drop the > packet in this case: >=20 >=20 > + =C2=A0=C2=A0=C2=A0 /* > + =C2=A0=C2=A0=C2=A0 =C2=A0* In closing down the socket, the SO_ACCEPTCON= N flag is removed > to > + =C2=A0=C2=A0=C2=A0 =C2=A0* prevent new connections from being establish= ed.=C2=A0 This means > that > + =C2=A0=C2=A0=C2=A0 =C2=A0* any frames in that were in the midst of bein= g processed could > + =C2=A0=C2=A0=C2=A0 =C2=A0* make it here.=C2=A0 Need to just drop the fr= ame. > + =C2=A0=C2=A0=C2=A0 =C2=A0*/ > + =C2=A0=C2=A0=C2=A0 if (TCPS_LISTEN =3D=3D tp->t_state) { > + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 TCPSTAT_INC(tcps_rcvwhileclosing)= ; > + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 goto drop; > + =C2=A0=C2=A0=C2=A0 } > =C2=A0 =C2=A0=C2=A0=C2=A0 KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_L= ISTEN", > =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 __func__)); >=20 >=20 > Or, if there's someone more familiar with the locking in these paths, > they may be able to come up with a way to restructure the locks and > logic to close this window. >=20 >=20 >=20 > -Matt >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Apr 4, 2013 at 6:33 PM, Rick Macklem < rmacklem@uoguelph.ca > > wrote: >=20 >=20 > Hi, >=20 > When pho@ was doing some NFS testing, he got the > following crash, which I can't figure out. (As far > as I can see, INP_WLOCK() is always held when > tp->t_state =3D TCPS_CLOSED and it is held from before > the test for TCPS_CLOSED in tcp_input() up until > the tcp_do_segment() call. As such, I don't see how > tp->t_state can be TCPS_CLOSED, but that seems to > be what causes the panic?) >=20 > The "umount -f" will result in: > =C2=A0 soshutdown(so, SHUT_WR); > =C2=A0 soclose(so); > being done by the krpc on the socket. >=20 > Anyone have any ideas on this? > pho@ wrote: > > I continued running the NFS tests and got this "panic: > > tcp_do_segment: > > TCPS_LISTEN". It's the second time I get this panic with the same > > test > > scenario, so it seems to be reproducible. The scenario is "umount > > -f" > > of a mount point that is very active. > > > > http://people.freebsd.org/~pho/stress/log/kostik555.txt >=20 > Thanks in advance for any help, rick > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to " freebsd-net-unsubscribe@freebsd.org > " >=20 >=20 >=20 >=20 > -- > Juan Mojica > Email: jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 05:18:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B2252C7 for ; Mon, 8 Apr 2013 05:18:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 06ECC160 for ; Mon, 8 Apr 2013 05:18:43 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id f10so2470443dak.39 for ; Sun, 07 Apr 2013 22:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=IXDdbYgHNJmCF284oVPQmshA2HhCLfV18DaEAzNGUUA=; b=JFVTyt67BariClcDi9BqhpBCrlr+ognv21Jo6/P9mOGKCsxoYo2mmRbh/6T4SXb93c 6xE56ADGAybyMHM63plk7a2ajIZrdSBTEhlvA9MyR+QE+GZ+7FWmomjx8V8/j7PzC4ux 1WhBH81ZVICSMdG8qpSMPLyq6Y4YYCZHphSSqCNeRF6l5Ai6FAp5irIcYAvV1Xevjbym kqn8zjdVP1/qITalaHBjxmS63teHr/LckjF0JIDjGXycF3ky63FtBWXg+pOpH8fqw2vb Pm8lq5XsEhwLKHCLxwx5/7EofIrnFFXeT6YWBTRklq4ibLIlij9XstRfC4XDUizp5woL wZhA== X-Received: by 10.66.123.5 with SMTP id lw5mr34401305pab.132.1365398322601; Sun, 07 Apr 2013 22:18:42 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ux10sm36229417pab.1.2013.04.07.22.18.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 07 Apr 2013 22:18:41 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 08 Apr 2013 14:18:36 +0900 From: YongHyeon PYUN Date: Mon, 8 Apr 2013 14:18:36 +0900 To: "Eggert, Lars" Subject: Re: enable tcpdump GUESS_TSO flag? Message-ID: <20130408051836.GA1526@michelle.cdnetworks.com> References: <0A5ED929-C148-45C3-8576-C31D2C05AB04@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A5ED929-C148-45C3-8576-C31D2C05AB04@netapp.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 05:18:43 -0000 On Thu, Apr 04, 2013 at 11:24:18AM +0000, Eggert, Lars wrote: > Hi, > > I wonder whether it'd be a good idea to enable tcpdump's GUESS_TSO flag by default? It enables a heuristic that lets tcpdump understand pcaps that include segments generated by TCP TSO (which otherwise show up as "IP bad-len 0".) > I don't have strong option on enabling that flag but I think it would be even better to have an option to enable/disable that feature(default off). em(4) controllers require IP length should be 0 before controller performs TSO operation. fxp(4) controllers requires IP length should be set to the IP length of the first TCP segment after TSO operation. bpf listeners see the modified packet so it can confuse them. AFAIK, except em(4)/fxp(4) controllers, no other controllers in tree have such limitation with TSO. Enabling GUESS_TSO flag may make it hard to debug network/driver issues I guess. > See the dicussion at http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/msg01051.html for details. > > Lars > > diff --git a/usr.sbin/tcpdump/tcpdump/Makefile b/usr.sbin/tcpdump/tcpdump/Makefile > index ca8ec4c..5fd73a1 100644 > --- a/usr.sbin/tcpdump/tcpdump/Makefile > +++ b/usr.sbin/tcpdump/tcpdump/Makefile > @@ -45,6 +45,10 @@ CFLAGS+= -I${.CURDIR} -I${TCPDUMP_DISTDIR} > CFLAGS+= -DHAVE_CONFIG_H > CFLAGS+= -D_U_="__attribute__((unused))" > > +# Enable tcpdump heuristic to identify TSO-generated packets; see > +# http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/msg01051.html > +CFLAGS+= -DGUESS_TSO > + > .if ${MK_INET6_SUPPORT} != "no" > SRCS+= print-ip6.c print-ip6opts.c print-mobility.c print-ripng.c \ > print-icmp6.c print-babel.c print-frag6.c print-rt6.c print-ospf6.c \ > From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 10:15:47 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDD8D50D; Mon, 8 Apr 2013 10:15:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 98DC7C2; Mon, 8 Apr 2013 10:15:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r38AFl8a047864; Mon, 8 Apr 2013 10:15:47 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r38AFlrM047863; Mon, 8 Apr 2013 10:15:47 GMT (envelope-from ae) Date: Mon, 8 Apr 2013 10:15:47 GMT Message-Id: <201304081015.r38AFlrM047863@freefall.freebsd.org> To: hiren.panchasara@gmail.com, ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/177696: [patch] [net] Removing an unavailable sysctl from manpage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 10:15:47 -0000 Synopsis: [patch] [net] Removing an unavailable sysctl from manpage State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Mon Apr 8 10:15:00 UTC 2013 State-Changed-Why: Committed to the head/. Thanks! Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Mon Apr 8 10:15:00 UTC 2013 Responsible-Changed-Why: Take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=177696 From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 11:01:45 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0F098F34; Mon, 8 Apr 2013 11:01:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A834F2C3; Mon, 8 Apr 2013 11:01:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r38B1ikE055921; Mon, 8 Apr 2013 11:01:44 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r38B1hMH055920; Mon, 8 Apr 2013 11:01:43 GMT (envelope-from glebius) Date: Mon, 8 Apr 2013 11:01:43 GMT Message-Id: <201304081101.r38B1hMH055920@freefall.freebsd.org> To: lglion718@163.com, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Subject: Re: kern/177456: [tcp] [patch] An error of calculating TCP sequence number will resault in the machine to restart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:01:45 -0000 Synopsis: [tcp] [patch] An error of calculating TCP sequence number will resault in the machine to restart State-Changed-From-To: open->analyzed State-Changed-By: glebius State-Changed-When: Mon Apr 8 11:01:18 UTC 2013 State-Changed-Why: Grab the PR. I've reproduced it. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Mon Apr 8 11:01:18 UTC 2013 Responsible-Changed-Why: Grab the PR. I've reproduced it. http://www.freebsd.org/cgi/query-pr.cgi?pr=177456 From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A7F322E for ; Mon, 8 Apr 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4B52035E for ; Mon, 8 Apr 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r38B6nAY057315 for ; Mon, 8 Apr 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r38B6mEC057313 for freebsd-net@FreeBSD.org; Mon, 8 Apr 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Apr 2013 11:06:48 GMT Message-Id: <201304081106.r38B6mEC057313@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod o kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 461 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 11:40:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 067E6196; Mon, 8 Apr 2013 11:40:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 941E88C8; Mon, 8 Apr 2013 11:40:31 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 8 Apr 2013 13:40:01 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 8 Apr 2013 13:40:02 +0200 Date: Mon, 8 Apr 2013 13:40:07 +0200 From: Harti Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Lev Serebryakov Subject: Re: BSNMPD: several (cosmetic?) problems In-Reply-To: <563362676.20130407121102@serebryakov.spb.ru> Message-ID: References: <563362676.20130407121102@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:40:32 -0000 Hi, On Sun, 7 Apr 2013, Lev Serebryakov wrote: LS>(1) I have a lot of "could not encode error response" in LS>/var/log/messages after change of hardware. It looks like, every LS>request from mrtg for "unexistent" interface leads to this message. LS>I'll reconfigure mrtg, of course, but it is annoying. I think this is a problem I have already got a patch for from Steryana, but did not manage yet to test. If it is that problem, then it is not entirely cosmetic, because the daemon fails to send error responses in many cases. harti LS>(2) With wlan plugin daemon complains "unknown regdomain (0x8a)", and LS>I have "regdomain ROW country DE" on my WiFi card. LS> LS> From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 11:51:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E29672E9; Mon, 8 Apr 2013 11:51:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A8A12924; Mon, 8 Apr 2013 11:51:28 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:900d:c887:884e:713b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 156CC4AC57; Mon, 8 Apr 2013 15:51:27 +0400 (MSK) Date: Mon, 8 Apr 2013 15:51:24 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1192096458.20130408155124@serebryakov.spb.ru> To: Harti Brandt Subject: Re: BSNMPD: several (cosmetic?) problems In-Reply-To: References: <563362676.20130407121102@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Harti Brandt X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:51:29 -0000 Hello, Harti. You wrote 8 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 15:40:07: LS>>(1) I have a lot of "could not encode error response" in LS>>/var/log/messages after change of hardware. It looks like, every LS>>request from mrtg for "unexistent" interface leads to this message. LS>>I'll reconfigure mrtg, of course, but it is annoying. HB> I think this is a problem I have already got a patch for from Steryana, HB> but did not manage yet to test. If it is that problem, then it is not= =20 HB> entirely cosmetic, because the daemon fails to send error responses in HB> many cases. Could you send this patch to me for test? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 12:06:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 721486E8; Mon, 8 Apr 2013 12:06:00 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 224C39F1; Mon, 8 Apr 2013 12:06:00 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id ni5so1098779obc.9 for ; Mon, 08 Apr 2013 05:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qOQIMp/acwHFgsVAEWpr9jDifpE/QSbogr9CmKY45gc=; b=Bt0Ofk2Q08NfzoL+xWHUPCWlC5Exc7MBuUKxIU9zbxn4LWK3lF/qr8wbpmItcvZ6FS Px7z2jhh+HX44Tefn+e6JYa3bXst2ChnKEkjN/gbCGvFxpXszZ6Bxmed8qD4F/i1I6o6 LEddS0SWf9biAHnboHMxE+hvt+FR5OoPR4QN77mB/ELzyvWz3AjZAmY4Lcqt3ZECTBA3 kR4v+8TskyKUpCyQLzLfr7bSfFMVjfYtuiI+FFERMwR3pKdPOQlyUKJzoXjxA3gBe6XL fsZQ6dBx0HNZaDjKuaMXiTL2AMTTEWwRzQn/05FScYlXrpJlI+xomRxgCRzyIu5MPU71 Nt9w== MIME-Version: 1.0 X-Received: by 10.60.54.6 with SMTP id f6mr8413702oep.136.1365422758984; Mon, 08 Apr 2013 05:05:58 -0700 (PDT) Sender: shteryana@gmail.com Received: by 10.76.150.195 with HTTP; Mon, 8 Apr 2013 05:05:58 -0700 (PDT) In-Reply-To: <1192096458.20130408155124@serebryakov.spb.ru> References: <563362676.20130407121102@serebryakov.spb.ru> <1192096458.20130408155124@serebryakov.spb.ru> Date: Mon, 8 Apr 2013 15:05:58 +0300 X-Google-Sender-Auth: Qawqj8YFGcchyBrxgjPglov8qH8 Message-ID: Subject: Re: BSNMPD: several (cosmetic?) problems From: Shteryana Shopova To: lev@freebsd.org Content-Type: multipart/mixed; boundary=089e011763b984832f04d9d842a0 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@FreeBSD.org" , Harti Brandt , Harti Brandt X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:06:00 -0000 --089e011763b984832f04d9d842a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The patch in question can be found at http://people.freebsd.org/~syrinx/snmp/libbsnmp-20121029-01.diff , I am also attaching it to this e-mail. I didn't commit it yet, since I did not manage to get it properly reviewed or get confirmation from Harti that it solved his problem. Error responses worked fine when I last tested the patch, but it's always good to receive feedback from other testers. cheers, Shteryana On Mon, Apr 8, 2013 at 2:51 PM, Lev Serebryakov wrote: > Hello, Harti. > You wrote 8 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 15:40:07: > > LS>>(1) I have a lot of "could not encode error response" in > LS>>/var/log/messages after change of hardware. It looks like, every > LS>>request from mrtg for "unexistent" interface leads to this message. > LS>>I'll reconfigure mrtg, of course, but it is annoying. > HB> I think this is a problem I have already got a patch for from Steryan= a, > HB> but did not manage yet to test. If it is that problem, then it is not > HB> entirely cosmetic, because the daemon fails to send error responses i= n > HB> many cases. > Could you send this patch to me for test? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --089e011763b984832f04d9d842a0 Content-Type: application/octet-stream; name="libbsnmp-20121029-01.diff" Content-Disposition: attachment; filename="libbsnmp-20121029-01.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hf9lg0p60 SW5kZXg6IHNubXAuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzbm1wLmgJKHJldmlzaW9uIDI0MTY4NSkKKysr IHNubXAuaAkod29ya2luZyBjb3B5KQpAQCAtMTgyLDcgKzE4Miw3IEBACiAKIAkvKiBmaXhlcyBm b3IgZW5jb2RpbmcgKi8KIAlzaXplX3QJCQlvdXRlcl9sZW47Ci0Jc2l6ZV90CQkJc2NvcGVkX2xl bjsKKwlhc25fbGVuX3QJCXNjb3BlZF9sZW47CiAJdV9jaGFyCQkJKm91dGVyX3B0cjsKIAl1X2No YXIJCQkqZGlnZXN0X3B0cjsKIAl1X2NoYXIJCQkqZW5jcnlwdGVkX3B0cjsKSW5kZXg6IHNubXBh Z2VudC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHNubXBhZ2VudC5jCShyZXZpc2lvbiAyNDE2ODUpCisrKyBz bm1wYWdlbnQuYwkod29ya2luZyBjb3B5KQpAQCAtMTY2LDcgKzE2Niw3IEBACiB9CiAKIHN0YXRp YyB2b2lkCi1zbm1wX3BkdV9jcmVhdGVfcmVzcG9uc2Uoc3RydWN0IHNubXBfcGR1ICpwZHUsIHN0 cnVjdCBzbm1wX3BkdSAqcmVzcCkKK3NubXBfcGR1X2NyZWF0ZV9yZXNwb25zZShjb25zdCBzdHJ1 Y3Qgc25tcF9wZHUgKnBkdSwgc3RydWN0IHNubXBfcGR1ICpyZXNwKQogewogCW1lbXNldChyZXNw LCAwLCBzaXplb2YoKnJlc3ApKTsKIAlzdHJjcHkocmVzcC0+Y29tbXVuaXR5LCBwZHUtPmNvbW11 bml0eSk7CkBAIC05NTIsMTkgKzk1Miw1OCBAQAogc25tcF9tYWtlX2VycnJlc3AoY29uc3Qgc3Ry dWN0IHNubXBfcGR1ICpwZHUsIHN0cnVjdCBhc25fYnVmICpwZHVfYiwKICAgICBzdHJ1Y3QgYXNu X2J1ZiAqcmVzcF9iKQogeworCXVfY2hhciB0eXBlOwogCWFzbl9sZW5fdCBsZW47CiAJc3RydWN0 IHNubXBfcGR1IHJlc3A7CiAJZW51bSBhc25fZXJyIGVycjsKIAllbnVtIHNubXBfY29kZSBjb2Rl OwogCi0JbWVtc2V0KCZyZXNwLCAwLCBzaXplb2YocmVzcCkpOworCXNubXBfcGR1X2NyZWF0ZV9y ZXNwb25zZShwZHUsICZyZXNwKTsKKwogCWlmICgoY29kZSA9IHNubXBfcGR1X2RlY29kZV9oZWFk ZXIocGR1X2IsICZyZXNwKSkgIT0gU05NUF9DT0RFX09LKQogCQlyZXR1cm4gKFNOTVBfUkVUX0lH Tik7CiAKLQlpZiAocGR1X2ItPmFzbl9sZW4gPCBsZW4pCi0JCXJldHVybiAoU05NUF9SRVRfSUdO KTsKLQlwZHVfYi0+YXNuX2xlbiA9IGxlbjsKKwlpZiAocGR1LT52ZXJzaW9uID09IFNOTVBfVjMp IHsKKwkJaWYgKHJlc3AudXNlci5wcml2X3Byb3RvICE9IFNOTVBfUFJJVl9OT1BSSVYgJiYKKwkJ ICAgKGFzbl9nZXRfaGVhZGVyKHBkdV9iLCAmdHlwZSwgJnJlc3Auc2NvcGVkX2xlbikgIT0gQVNO X0VSUl9PSworCQkgICB8fCB0eXBlICE9IEFTTl9UWVBFX09DVEVUU1RSSU5HKSkgeworCQkJc25t cF9lcnJvcigiY2Fubm90IGRlY29kZSBlbmNyeXB0ZWQgcGR1Iik7CisJCQlyZXR1cm4gKFNOTVBf Q09ERV9GQUlMRUQpOworCQl9CiAKKwkJaWYgKGFzbl9nZXRfc2VxdWVuY2UocGR1X2IsICZsZW4p ICE9IEFTTl9FUlJfT0spIHsKKwkJCXNubXBfZXJyb3IoImNhbm5vdCBkZWNvZGUgc2NvcGVkIHBk dSBoZWFkZXIiKTsKKwkJCXJldHVybiAoU05NUF9DT0RFX0ZBSUxFRCk7CisJCX0KKworCQlsZW4g PSBTTk1QX0VOR0lORV9JRF9TSVo7CisJCWlmIChhc25fZ2V0X29jdGV0c3RyaW5nKHBkdV9iLCAo dV9jaGFyICopcmVzcC5jb250ZXh0X2VuZ2luZSwKKwkJICAgICZsZW4pICE9IEFTTl9FUlJfT0sp IHsKKwkJCXNubXBfZXJyb3IoImNhbm5vdCBkZWNvZGUgbXNnIGNvbnRleHQgZW5naW5lIik7CisJ CQlyZXR1cm4gKFNOTVBfQ09ERV9GQUlMRUQpOworCQl9CisJCXJlc3AuY29udGV4dF9lbmdpbmVf bGVuID0gbGVuOworCQlsZW4gPSBTTk1QX0NPTlRFWFRfTkFNRV9TSVo7CisJCWlmIChhc25fZ2V0 X29jdGV0c3RyaW5nKHBkdV9iLCAodV9jaGFyICopcmVzcC5jb250ZXh0X25hbWUsCisJCSAgICAm bGVuKSAhPSBBU05fRVJSX09LKSB7CisJCQlzbm1wX2Vycm9yKCJjYW5ub3QgZGVjb2RlIG1zZyBj b250ZXh0IG5hbWUiKTsKKwkJCXJldHVybiAoU05NUF9DT0RFX0ZBSUxFRCk7CisJCX0KKwkJcmVz cC5jb250ZXh0X25hbWVbbGVuXSA9ICdcMCc7CisJfQorCisKKwlpZiAoYXNuX2dldF9oZWFkZXIo cGR1X2IsICZ0eXBlLCAmbGVuKSAhPSBBU05fRVJSX09LKSB7CisJCXNubXBfZXJyb3IoImNhbm5v dCBnZXQgcGR1IGhlYWRlciIpOworCQlyZXR1cm4gKFNOTVBfQ09ERV9GQUlMRUQpOworCX0KKwor CWlmICgodHlwZSAmIH5BU05fVFlQRV9NQVNLKSAhPQorCSAgICAoQVNOX1RZUEVfQ09OU1RSVUNU RUQgfCBBU05fQ0xBU1NfQ09OVEVYVCkpIHsKKwkJc25tcF9lcnJvcigiYmFkIHBkdSBoZWFkZXIg dGFnIik7CisJCXJldHVybiAoU05NUF9DT0RFX0ZBSUxFRCk7CisJfQorCiAJZXJyID0gc25tcF9w YXJzZV9wZHVzX2hkcihwZHVfYiwgJnJlc3AsICZsZW4pOwogCWlmIChBU05fRVJSX1NUT1BQRUQo ZXJyKSkKIAkJcmV0dXJuIChTTk1QX1JFVF9JR04pOwo= --089e011763b984832f04d9d842a0-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 12:13:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11219A4B for ; Mon, 8 Apr 2013 12:13:49 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D81BA4B for ; Mon, 8 Apr 2013 12:13:48 +0000 (UTC) Received: (qmail 71522 invoked from network); 8 Apr 2013 13:21:21 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Apr 2013 13:21:21 -0000 Message-ID: <5162B474.6060808@freebsd.org> Date: Mon, 08 Apr 2013 14:13:40 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Matt Miller Subject: Re: panic in tcp_do_segment() References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Juan Mojica , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:13:49 -0000 On 05.04.2013 13:09, Matt Miller wrote: > Hey Rick, > > I believe Juan and I have root caused this crash recently. The t_state = > 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. > > In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the > socket and we should never enter tcp_do_segment() for this state. I think > if you look in your corefile, you'll see the socket *doesn't* have this > flag set in your case. > > 1043 /* > 1044 * When the socket is accepting connections (the INPCB is in > LISTEN > 1045 * state) we look into the SYN cache if this is a new > connection > 1046 * attempt or the completion of a previous one. Because listen > 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock > will be > 1048 * held in this case. > 1049 */ > 1050 if (so->so_options & SO_ACCEPTCONN) { > 1051 struct in_conninfo inc; > 1052 > 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so accepting > but " > 1054 "tp not listening", __func__)); > ... > 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); > 1357 /* > 1358 * Entry added to syncache and mbuf consumed. > 1359 * Everything already unlocked by syncache_add(). > 1360 */ > 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > 1362 return; > 1363 } > ... > 1384 /* > 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or > later > 1386 * state. tcp_do_segment() always consumes the mbuf chain, > unlocks > 1387 * the inpcb, and unlocks pcbinfo. > 1388 */ > 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, > ti_locked); > > I think this has to do with this patch in soclose() where SO_ACCEPTCONN is > being turned off in soclose(). I suspect if you look at the other threads > in your corefile, you'll see one at this point in soclose() operating on > the same socket as the one in the tcp_do_segment() thread. > > http://svnweb.freebsd.org/base?view=revision&revision=243627 > > 817 /* > 818 * Prevent new additions to the accept queues due > 819 * to ACCEPT_LOCK races while we are draining them. > 820 */ > 821 so->so_options &= ~SO_ACCEPTCONN; > 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { > 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); > 824 so->so_incqlen--; > 825 sp->so_qstate &= ~SQ_INCOMP; > 826 sp->so_head = NULL; > 827 ACCEPT_UNLOCK(); > 828 soabort(sp); > 829 ACCEPT_LOCK(); > 830 } > > Juan had evaluated this code path and it seemed safe to just drop the > packet in this case: > > + /* > + * In closing down the socket, the SO_ACCEPTCONN flag is removed to > + * prevent new connections from being established. This means that > + * any frames in that were in the midst of being processed could > + * make it here. Need to just drop the frame. > + */ > + if (TCPS_LISTEN == tp->t_state) { > + TCPSTAT_INC(tcps_rcvwhileclosing); > + goto drop; > + } > KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > __func__)); > > Or, if there's someone more familiar with the locking in these paths, they > may be able to come up with a way to restructure the locks and logic to > close this window. Matt, Juan, excellent analysis. I don't see a better approach to handle this under the current ACCEPT_LOCK model. Compared to your patch I'd like to handle this race earlier before we hit tcp_do_segment(). Could you please review the attached patch which handles it right after the SO_ACCEPTCONN / syncache check? -- Andre Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 249253) +++ netinet/tcp_input.c (working copy) @@ -1351,6 +1351,16 @@ */ INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); return; + } else if (tp->t_state == TCPS_LISTEN) { + /* + * When a listen socket is torn down the SO_ACCEPTCONN + * flag is removed first while connections are drained + * from the accept queue in a unlock/lock cycle of the + * ACCEPT_LOCK, opening a race condition allowing a SYN + * attempt go through unhandled. + */ + TCPSTAT_INC(tcps_rcvdwhileclosing); + goto drop; } #ifdef TCP_SIGNATURE From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 14:52:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31D0C61C for ; Mon, 8 Apr 2013 14:52:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id B1AF11E0 for ; Mon, 8 Apr 2013 14:52:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r38EqBXV045705; Mon, 8 Apr 2013 18:52:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r38EqBmt045704; Mon, 8 Apr 2013 18:52:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 8 Apr 2013 18:52:11 +0400 From: Gleb Smirnoff To: Sepherosa Ziehau Subject: Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart Message-ID: <20130408145211.GE76816@glebius.int.ru> References: <201304031530.r33FU1AY097998@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:52:23 -0000 Sephe, On Sat, Apr 06, 2013 at 06:04:25PM +0800, Sepherosa Ziehau wrote: S> Hope the following analysis helps; IMHO, the reporter probably had hit S> the same bug: S> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/1ff9b7d322dc5a26f7173aa8c38ecb79da80e419 Thanks for hint! The commit message describes the case clearly. Bug confirmed. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 17:30:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C78D28A1 for ; Mon, 8 Apr 2013 17:30:13 +0000 (UTC) (envelope-from VenkatKumar.Duvvuru@Emulex.Com) Received: from CMEXEDGE1.ext.emulex.com (cmexedge1.ext.emulex.com [138.239.224.99]) by mx1.freebsd.org (Postfix) with ESMTP id 914F2CD0 for ; Mon, 8 Apr 2013 17:30:13 +0000 (UTC) Received: from CMEXHTCAS2.ad.emulex.com (138.239.115.218) by CMEXEDGE1.ext.emulex.com (138.239.224.99) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 8 Apr 2013 10:15:36 -0700 Received: from CMEXMB1.ad.emulex.com ([169.254.1.136]) by CMEXHTCAS2.ad.emulex.com ([2002:8aef:71b8::8aef:71b8]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 10:14:58 -0700 From: "Duvvuru,Venkat Kumar" To: "freebsd-net@freebsd.org" Subject: drbr_enqueue - OCE driver - Freebsd 9.1 Thread-Topic: drbr_enqueue - OCE driver - Freebsd 9.1 Thread-Index: Ac40fItUT8/z+mHWRfWrn38wP/SoOw== Date: Mon, 8 Apr 2013 17:14:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.226.252.152] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:30:13 -0000 Hi, In the transmit path, if enqueue mechanism is used instead of blocking on t= he lock, the throughput is not good in some scenarios (especially single qu= eue, multiple connections). For example: if (TRY_LOCK(&wq->tx_lock)) { status =3D oce_multiq_transmit(ifp, m, wq); UNLOCK(&wq->tx_lock); } else { status =3D drbr_enqueue(ifp, wq->br, m); } Instead of the above code where the request is enqueued if I use a normal L= OCK and block on it, it is giving good performance. Any suggestions on why the throughput is low in case of enqueue mechanism. Thx, Venkat. From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 18:34:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B939851 for ; Mon, 8 Apr 2013 18:34:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 38CD3FE6 for ; Mon, 8 Apr 2013 18:34:51 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so4173913wib.5 for ; Mon, 08 Apr 2013 11:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mYZIN9jWAin2kLz1dt4BgN87EVTfubZZt5TPfzD3kds=; b=beO/wEBnmRizs0YjW9NRphqTR5kPhIG4wDxVbvoPp/d/Qj9YgG5pSUjnqwfJ7se/Ot 9A2Q6cF5SYSHYThym/YUehvl1Jtj9j0keAVdFEsEQz6G4plkeJLIAL2a+MAcJLuE73Yl gD9/8YS1f8mFWGoi6IV+Fzdqxs3LhQEQHXyefIklT2MJKAafiAuZAeZ0js8qdTvq1ysJ sgie2CfjwRTsf2rx09Rg5RFTrhRN+9pEZAGj5zWG1qHgcsEgwIh5Fai/lkgyRo43qtHv ggKnRbeFFwwfoKS1WPivnpx4lWz1J4B4ZhhW9VEqxodPPB/mFDXTHrELkNZ5wthVaDtk UljA== MIME-Version: 1.0 X-Received: by 10.180.19.39 with SMTP id b7mr14983009wie.15.1365446090451; Mon, 08 Apr 2013 11:34:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.121.136 with HTTP; Mon, 8 Apr 2013 11:34:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 11:34:50 -0700 X-Google-Sender-Auth: H5KWXE5WLsIIJXVYePl3-ok0rXA Message-ID: Subject: Re: drbr_enqueue - OCE driver - Freebsd 9.1 From: Adrian Chadd To: "Duvvuru,Venkat Kumar" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:34:51 -0000 On 8 April 2013 10:14, Duvvuru,Venkat Kumar wrote: > Hi, > In the transmit path, if enqueue mechanism is used instead of blocking on the lock, the throughput is not good in some scenarios (especially single queue, multiple connections). > For example: > if (TRY_LOCK(&wq->tx_lock)) { > status = oce_multiq_transmit(ifp, m, wq); > UNLOCK(&wq->tx_lock); > } else { > status = drbr_enqueue(ifp, wq->br, m); > } > > Instead of the above code where the request is enqueued if I use a normal LOCK and block on it, it is giving good performance. > > Any suggestions on why the throughput is low in case of enqueue mechanism. You'll have to do a little more digging: * Is your application spewing TCP or UDP traffic? Or sometihng else? * are frames filling up the drbr enqueue and being dropped? having a lock means that the caller will block until the transmit completes, so traffic isn't immediately dropped as a side effect; * is the driver correctly checking the drbr queue when it finishes a transmit? In fact - oce_multiq_transmit should not be transmitting that mbuf, it should be enqueueing to the end of the drbr, then transmitting the head item in the drbr queue. Otherwise you may get out of order packets. adrian From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 18:57:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B4EF60D; Mon, 8 Apr 2013 18:57:59 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx1.freebsd.org (Postfix) with ESMTP id 718151AD; Mon, 8 Apr 2013 18:57:57 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id s10so6086718lbi.19 for ; Mon, 08 Apr 2013 11:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=q4JFtqxXZRPftybh+h3id/kWWTI87V+s4XAdenAJfZI=; b=Hx9aj9kwkhPBKp2MMo6vJNZD5cr9GYaRWGP/FSHj1ZuDeaPWTxizibSIPIrWY2yTKk V+ZFMqFCsopqmzI8M+yX/2+fF8nWA9sjlm4tpjQj4N0RXKrTgQNOgRKF2C0nJkGe9qpC DjBlnwlVwtWnuEYFnpapHZMaAjNg06oe+MOGoXaQNT6gZTCan/OZUer2v8BFpipQ0+C9 vyex1R2uscnA1nYrWG5j0D5l6gZc5Zm2Rd/h6wzjjlbAiwTs8J+DoV3pGUQhcpCwuyG3 dy3kuK4QBBMw5M3xCIOpHTNADMOFWZ741iNjN9sNRGNWdODAxTmdiYBNWu1Vb59hJ2we w7Zg== X-Received: by 10.152.110.74 with SMTP id hy10mr12252235lab.37.1365447476203; Mon, 08 Apr 2013 11:57:56 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.112.101.166 with HTTP; Mon, 8 Apr 2013 11:57:16 -0700 (PDT) In-Reply-To: <5162B474.6060808@freebsd.org> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> From: Matt Miller Date: Mon, 8 Apr 2013 14:57:16 -0400 X-Google-Sender-Auth: 12sfr5BB-3C4cDVQ3tcMWCZgkmw Message-ID: Subject: Re: panic in tcp_do_segment() To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Juan Mojica , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:57:59 -0000 Hey Andre, Looks OK to me. Note that tcps_rcvdwhileclosing is a new stat Juan added (I had omitted the rest of that diff b/c adding a new stat wasn't that interesting to the discussion). If you want that stat added, we can prepare a patch with the rest of the changes (or, I'm sure you know already know what else needs to be done for that). Just let us know if you want us to prepare the rest of the patch for that new stat or not. Thanks, Matt On Mon, Apr 8, 2013 at 8:13 AM, Andre Oppermann wrote: > On 05.04.2013 13:09, Matt Miller wrote: > >> Hey Rick, >> >> I believe Juan and I have root caused this crash recently. The t_state = >> 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. >> >> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on >> the >> socket and we should never enter tcp_do_segment() for this state. I think >> if you look in your corefile, you'll see the socket *doesn't* have this >> flag set in your case. >> >> 1043 /* >> 1044 * When the socket is accepting connections (the INPCB is in >> LISTEN >> 1045 * state) we look into the SYN cache if this is a new >> connection >> 1046 * attempt or the completion of a previous one. Because >> listen >> 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock >> will be >> 1048 * held in this case. >> 1049 */ >> 1050 if (so->so_options & SO_ACCEPTCONN) { >> 1051 struct in_conninfo inc; >> 1052 >> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so >> accepting >> but " >> 1054 "tp not listening", __func__)); >> ... >> 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); >> 1357 /* >> 1358 * Entry added to syncache and mbuf consumed. >> 1359 * Everything already unlocked by syncache_add(). >> 1360 */ >> 1361 INP_INFO_UNLOCK_ASSERT(&V_**tcbinfo); >> 1362 return; >> 1363 } >> ... >> 1384 /* >> 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED >> or >> later >> 1386 * state. tcp_do_segment() always consumes the mbuf chain, >> unlocks >> 1387 * the inpcb, and unlocks pcbinfo. >> 1388 */ >> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, >> ti_locked); >> >> I think this has to do with this patch in soclose() where SO_ACCEPTCONN is >> being turned off in soclose(). I suspect if you look at the other threads >> in your corefile, you'll see one at this point in soclose() operating on >> the same socket as the one in the tcp_do_segment() thread. >> >> http://svnweb.freebsd.org/**base?view=revision&revision=**243627 >> >> 817 /* >> 818 * Prevent new additions to the accept queues due >> 819 * to ACCEPT_LOCK races while we are draining them. >> 820 */ >> 821 so->so_options &= ~SO_ACCEPTCONN; >> 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { >> 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); >> 824 so->so_incqlen--; >> 825 sp->so_qstate &= ~SQ_INCOMP; >> 826 sp->so_head = NULL; >> 827 ACCEPT_UNLOCK(); >> 828 soabort(sp); >> 829 ACCEPT_LOCK(); >> 830 } >> >> Juan had evaluated this code path and it seemed safe to just drop the >> packet in this case: >> >> + /* >> + * In closing down the socket, the SO_ACCEPTCONN flag is removed to >> + * prevent new connections from being established. This means that >> + * any frames in that were in the midst of being processed could >> + * make it here. Need to just drop the frame. >> + */ >> + if (TCPS_LISTEN == tp->t_state) { >> + TCPSTAT_INC(tcps_**rcvwhileclosing); >> + goto drop; >> + } >> KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", >> __func__)); >> >> Or, if there's someone more familiar with the locking in these paths, they >> may be able to come up with a way to restructure the locks and logic to >> close this window. >> > > Matt, Juan, > > excellent analysis. I don't see a better approach to handle this > under the current ACCEPT_LOCK model. > > Compared to your patch I'd like to handle this race earlier before > we hit tcp_do_segment(). > > Could you please review the attached patch which handles it right > after the SO_ACCEPTCONN / syncache check? > > -- > Andre > > Index: netinet/tcp_input.c > ==============================**==============================**======= > --- netinet/tcp_input.c (revision 249253) > +++ netinet/tcp_input.c (working copy) > @@ -1351,6 +1351,16 @@ > */ > INP_INFO_UNLOCK_ASSERT(&V_**tcbinfo); > return; > + } else if (tp->t_state == TCPS_LISTEN) { > + /* > + * When a listen socket is torn down the SO_ACCEPTCONN > + * flag is removed first while connections are drained > + * from the accept queue in a unlock/lock cycle of the > + * ACCEPT_LOCK, opening a race condition allowing a SYN > + * attempt go through unhandled. > + */ > + TCPSTAT_INC(tcps_**rcvdwhileclosing); > + goto drop; > } > > #ifdef TCP_SIGNATURE > From owner-freebsd-net@FreeBSD.ORG Mon Apr 8 19:15:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB51EBE1 for ; Mon, 8 Apr 2013 19:15:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD14327A for ; Mon, 8 Apr 2013 19:15:33 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n12so6516775oag.41 for ; Mon, 08 Apr 2013 12:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gOggC9pZWx947QPLTKAV4+9lbxa6HHBaP/yH1WQRhU0=; b=KchV9KXleIPUHjxRtqGl85fkzrjDSXlZ+g6L/9l7vFnfGPO3p4l62i0znUMp2IVF1l 6XjgWLbldN9W1Yw4ABNjHOs1Ruq3dDQVAyWRMNgfgBKd7DlhHxSUZOWfV5kKj33TTqEy r5/QMKrMCwrLgsYPBAlLObcqD8zARACNe9QAN5bU+XGyA7//1/RtX8pLv2JXNOz7olO3 dN+cbi+TIMkbkndL0fHCxnqoOk3xcasUgdEE2p0LOTANh6bjOYp03dFxFXIuOU+ImS6N hT0ZGBAzy+/uoKxN6Xyku8wttBTAcytmtvaOG1wX8kJi2G6kx6cSyCB4pZhuma7uMarn aqGA== MIME-Version: 1.0 X-Received: by 10.182.166.10 with SMTP id zc10mr8689842obb.80.1365448532937; Mon, 08 Apr 2013 12:15:32 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Mon, 8 Apr 2013 12:15:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 15:15:32 -0400 Message-ID: Subject: Re: drbr_enqueue - OCE driver - Freebsd 9.1 From: Ryan Stone To: "Duvvuru,Venkat Kumar" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:15:33 -0000 On Mon, Apr 8, 2013 at 1:14 PM, Duvvuru,Venkat Kumar < VenkatKumar.Duvvuru@emulex.com> wrote: > Hi, > In the transmit path, if enqueue mechanism is used instead of blocking on > the lock, the throughput is not good in some scenarios (especially single > queue, multiple connections). > For example: > if (TRY_LOCK(&wq->tx_lock)) { > status = oce_multiq_transmit(ifp, m, wq); > UNLOCK(&wq->tx_lock); > } else { > status = drbr_enqueue(ifp, wq->br, m); > } > > Instead of the above code where the request is enqueued if I use a normal > LOCK and block on it, it is giving good performance. > > Any suggestions on why the throughput is low in case of enqueue mechanism. > > Thx, > Venkat. > Shouldn't you be triggering a taskqueue to actually transmit the packet in the "failed to acquire lock" case? Otherwise it could be held in the drbr indefinitely. From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 07:21:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E2116B3 for ; Tue, 9 Apr 2013 07:21:55 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 46C126CA for ; Tue, 9 Apr 2013 07:21:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,436,1363158000"; d="scan'208";a="38639435" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 09 Apr 2013 00:20:37 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r397KaVY011766; Tue, 9 Apr 2013 00:20:37 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Tue, 9 Apr 2013 00:20:36 -0700 From: "Eggert, Lars" To: "" Subject: Re: enable tcpdump GUESS_TSO flag? Thread-Topic: enable tcpdump GUESS_TSO flag? Thread-Index: AQHOMSbyh8pfApUoREqP7JnSG2YuopjMRBUAgAG0aoA= Date: Tue, 9 Apr 2013 07:20:35 +0000 Message-ID: <8EF28976-C8CF-43D0-B6D0-7547014E1AB9@netapp.com> References: <0A5ED929-C148-45C3-8576-C31D2C05AB04@netapp.com> <20130408051836.GA1526@michelle.cdnetworks.com> In-Reply-To: <20130408051836.GA1526@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <95CB60ED894BFA40A6A6F75AA18E2681@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:21:55 -0000 Hi, On Apr 8, 2013, at 7:18, YongHyeon PYUN wrote: > I don't have strong option on enabling that flag but I think it > would be even better to have an option to enable/disable that > feature(default off). I agree that would be the better solution, but it's a larger patch to the s= ource. > em(4) controllers require IP length should > be 0 before controller performs TSO operation. fxp(4) controllers > requires IP length should be set to the IP length of the first TCP > segment after TSO operation. bpf listeners see the modified packet > so it can confuse them. AFAIK, except em(4)/fxp(4) controllers, no > other controllers in tree have such limitation with TSO. Enabling > GUESS_TSO flag may make it hard to debug network/driver issues I > guess. Not sure. Yeah, you wouldn't see "IP bad-len 0" messages anymore in traces,= but instead those packets would contain garbage. That should still be noti= ceable to someone looking into the dump. Lars From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 08:16:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5640FE01 for ; Tue, 9 Apr 2013 08:16:57 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 0664A8CB for ; Tue, 9 Apr 2013 08:16:56 +0000 (UTC) Received: (qmail 77809 invoked from network); 9 Apr 2013 08:16:54 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay00.pair.com with SMTP; 9 Apr 2013 08:16:54 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r398Gre9050615; Tue, 9 Apr 2013 10:16:53 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r398GqqM050614; Tue, 9 Apr 2013 10:16:52 +0200 (CEST) (envelope-from pho) Date: Tue, 9 Apr 2013 10:16:52 +0200 From: Peter Holm To: Andre Oppermann Subject: Re: panic in tcp_do_segment() Message-ID: <20130409081652.GA50498@x2.osted.lan> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5162B474.6060808@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net , Juan Mojica , Matt Miller , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 08:16:57 -0000 On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote: > On 05.04.2013 13:09, Matt Miller wrote: > > Hey Rick, > > > > I believe Juan and I have root caused this crash recently. The t_state = > > 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. > > > > In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the > > socket and we should never enter tcp_do_segment() for this state. I think > > if you look in your corefile, you'll see the socket *doesn't* have this > > flag set in your case. > > > > 1043 /* > > 1044 * When the socket is accepting connections (the INPCB is in > > LISTEN > > 1045 * state) we look into the SYN cache if this is a new > > connection > > 1046 * attempt or the completion of a previous one. Because listen > > 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock > > will be > > 1048 * held in this case. > > 1049 */ > > 1050 if (so->so_options & SO_ACCEPTCONN) { > > 1051 struct in_conninfo inc; > > 1052 > > 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so accepting > > but " > > 1054 "tp not listening", __func__)); > > ... > > 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); > > 1357 /* > > 1358 * Entry added to syncache and mbuf consumed. > > 1359 * Everything already unlocked by syncache_add(). > > 1360 */ > > 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > > 1362 return; > > 1363 } > > ... > > 1384 /* > > 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or > > later > > 1386 * state. tcp_do_segment() always consumes the mbuf chain, > > unlocks > > 1387 * the inpcb, and unlocks pcbinfo. > > 1388 */ > > 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, > > ti_locked); > > > > I think this has to do with this patch in soclose() where SO_ACCEPTCONN is > > being turned off in soclose(). I suspect if you look at the other threads > > in your corefile, you'll see one at this point in soclose() operating on > > the same socket as the one in the tcp_do_segment() thread. > > > > http://svnweb.freebsd.org/base?view=revision&revision=243627 > > > > 817 /* > > 818 * Prevent new additions to the accept queues due > > 819 * to ACCEPT_LOCK races while we are draining them. > > 820 */ > > 821 so->so_options &= ~SO_ACCEPTCONN; > > 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { > > 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); > > 824 so->so_incqlen--; > > 825 sp->so_qstate &= ~SQ_INCOMP; > > 826 sp->so_head = NULL; > > 827 ACCEPT_UNLOCK(); > > 828 soabort(sp); > > 829 ACCEPT_LOCK(); > > 830 } > > > > Juan had evaluated this code path and it seemed safe to just drop the > > packet in this case: > > > > + /* > > + * In closing down the socket, the SO_ACCEPTCONN flag is removed to > > + * prevent new connections from being established. This means that > > + * any frames in that were in the midst of being processed could > > + * make it here. Need to just drop the frame. > > + */ > > + if (TCPS_LISTEN == tp->t_state) { > > + TCPSTAT_INC(tcps_rcvwhileclosing); > > + goto drop; > > + } > > KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > > __func__)); > > > > Or, if there's someone more familiar with the locking in these paths, they > > may be able to come up with a way to restructure the locks and logic to > > close this window. > > Matt, Juan, > > excellent analysis. I don't see a better approach to handle this > under the current ACCEPT_LOCK model. > > Compared to your patch I'd like to handle this race earlier before > we hit tcp_do_segment(). > > Could you please review the attached patch which handles it right > after the SO_ACCEPTCONN / syncache check? > > -- > Andre > > Index: netinet/tcp_input.c > =================================================================== > --- netinet/tcp_input.c (revision 249253) > +++ netinet/tcp_input.c (working copy) > @@ -1351,6 +1351,16 @@ > */ > INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > return; > + } else if (tp->t_state == TCPS_LISTEN) { > + /* > + * When a listen socket is torn down the SO_ACCEPTCONN > + * flag is removed first while connections are drained > + * from the accept queue in a unlock/lock cycle of the > + * ACCEPT_LOCK, opening a race condition allowing a SYN > + * attempt go through unhandled. > + */ > + TCPSTAT_INC(tcps_rcvdwhileclosing); > + goto drop; > } > > #ifdef TCP_SIGNATURE I was able to reproduce the original "panic: tcp_do_segment: TCPS_LISTEN" with ease; see http://people.freebsd.org/~pho/stress/log/tcp.txt. With your patch (minus the TCPSTAT_INC) I got this "panic: Lock (rw) tcp locked @ netinet/tcp_input.c:1432." http://people.freebsd.org/~pho/stress/log/tcp2.txt - Peter From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 08:35:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE80770E for ; Tue, 9 Apr 2013 08:35:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3746195C for ; Tue, 9 Apr 2013 08:35:32 +0000 (UTC) Received: (qmail 78496 invoked from network); 9 Apr 2013 09:43:02 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Apr 2013 09:43:02 -0000 Message-ID: <5163D2D2.2090407@freebsd.org> Date: Tue, 09 Apr 2013 10:35:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Peter Holm Subject: Re: panic in tcp_do_segment() References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> <20130409081652.GA50498@x2.osted.lan> In-Reply-To: <20130409081652.GA50498@x2.osted.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Juan Mojica , Matt Miller , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 08:35:33 -0000 On 09.04.2013 10:16, Peter Holm wrote: > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote: >> On 05.04.2013 13:09, Matt Miller wrote: >>> Hey Rick, >>> >>> I believe Juan and I have root caused this crash recently. The t_state = >>> 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. >>> >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the >>> socket and we should never enter tcp_do_segment() for this state. I think >>> if you look in your corefile, you'll see the socket *doesn't* have this >>> flag set in your case. >>> >>> 1043 /* >>> 1044 * When the socket is accepting connections (the INPCB is in >>> LISTEN >>> 1045 * state) we look into the SYN cache if this is a new >>> connection >>> 1046 * attempt or the completion of a previous one. Because listen >>> 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock >>> will be >>> 1048 * held in this case. >>> 1049 */ >>> 1050 if (so->so_options & SO_ACCEPTCONN) { >>> 1051 struct in_conninfo inc; >>> 1052 >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so accepting >>> but " >>> 1054 "tp not listening", __func__)); >>> ... >>> 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); >>> 1357 /* >>> 1358 * Entry added to syncache and mbuf consumed. >>> 1359 * Everything already unlocked by syncache_add(). >>> 1360 */ >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); >>> 1362 return; >>> 1363 } >>> ... >>> 1384 /* >>> 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or >>> later >>> 1386 * state. tcp_do_segment() always consumes the mbuf chain, >>> unlocks >>> 1387 * the inpcb, and unlocks pcbinfo. >>> 1388 */ >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, >>> ti_locked); >>> >>> I think this has to do with this patch in soclose() where SO_ACCEPTCONN is >>> being turned off in soclose(). I suspect if you look at the other threads >>> in your corefile, you'll see one at this point in soclose() operating on >>> the same socket as the one in the tcp_do_segment() thread. >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=243627 >>> >>> 817 /* >>> 818 * Prevent new additions to the accept queues due >>> 819 * to ACCEPT_LOCK races while we are draining them. >>> 820 */ >>> 821 so->so_options &= ~SO_ACCEPTCONN; >>> 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { >>> 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); >>> 824 so->so_incqlen--; >>> 825 sp->so_qstate &= ~SQ_INCOMP; >>> 826 sp->so_head = NULL; >>> 827 ACCEPT_UNLOCK(); >>> 828 soabort(sp); >>> 829 ACCEPT_LOCK(); >>> 830 } >>> >>> Juan had evaluated this code path and it seemed safe to just drop the >>> packet in this case: >>> >>> + /* >>> + * In closing down the socket, the SO_ACCEPTCONN flag is removed to >>> + * prevent new connections from being established. This means that >>> + * any frames in that were in the midst of being processed could >>> + * make it here. Need to just drop the frame. >>> + */ >>> + if (TCPS_LISTEN == tp->t_state) { >>> + TCPSTAT_INC(tcps_rcvwhileclosing); >>> + goto drop; >>> + } >>> KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", >>> __func__)); >>> >>> Or, if there's someone more familiar with the locking in these paths, they >>> may be able to come up with a way to restructure the locks and logic to >>> close this window. >> >> Matt, Juan, >> >> excellent analysis. I don't see a better approach to handle this >> under the current ACCEPT_LOCK model. >> >> Compared to your patch I'd like to handle this race earlier before >> we hit tcp_do_segment(). >> >> Could you please review the attached patch which handles it right >> after the SO_ACCEPTCONN / syncache check? >> >> -- >> Andre >> >> Index: netinet/tcp_input.c >> =================================================================== >> --- netinet/tcp_input.c (revision 249253) >> +++ netinet/tcp_input.c (working copy) >> @@ -1351,6 +1351,16 @@ >> */ >> INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); >> return; >> + } else if (tp->t_state == TCPS_LISTEN) { >> + /* >> + * When a listen socket is torn down the SO_ACCEPTCONN >> + * flag is removed first while connections are drained >> + * from the accept queue in a unlock/lock cycle of the >> + * ACCEPT_LOCK, opening a race condition allowing a SYN >> + * attempt go through unhandled. >> + */ >> + TCPSTAT_INC(tcps_rcvdwhileclosing); >> + goto drop; >> } >> >> #ifdef TCP_SIGNATURE > > I was able to reproduce the original "panic: tcp_do_segment: > TCPS_LISTEN" with ease; see > http://people.freebsd.org/~pho/stress/log/tcp.txt. > > With your patch (minus the TCPSTAT_INC) I got this "panic: Lock (rw) > tcp locked @ netinet/tcp_input.c:1432." > > http://people.freebsd.org/~pho/stress/log/tcp2.txt Please replace the 'goto drop' with 'goto dropunlock' to fix the panic. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 10:43:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 760977CB for ; Tue, 9 Apr 2013 10:43:37 +0000 (UTC) (envelope-from rlp@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF3E92 for ; Tue, 9 Apr 2013 10:43:36 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 10028EBDCE for ; Tue, 9 Apr 2013 12:43:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id JlW+JiOc5MOv for ; Tue, 9 Apr 2013 12:43:29 +0200 (CEST) Received: from [10.0.2.212] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 775ABEBD4D for ; Tue, 9 Apr 2013 12:43:29 +0200 (CEST) Message-ID: <5163F0D1.1060206@semihalf.com> Date: Tue, 09 Apr 2013 12:43:29 +0200 From: Pablo Ribalta Lorenzo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Bridge of vlan with a bridge Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 10:43:37 -0000 Hi there, Lately I was experiencing an issue while trying to recreate a particular setup for my networking interfaces that I would like to share. I'm running FreeBSD 8.3, but I also see the same issue in FreeBSD 10.0 (CURRENT). My setup looks like this: em0 --- vlan0 / \ \ / \ \ eth0 --- eth0.100 bridge0 bridge1 \ / / \ / / em1 --- vlan1 |----------------| |------------------------| Linux FreeBSD Where eth0 and eth0.100 are interfaces in a Linux PC. The rest of the interfaces belong to the FreeBSD setup and you can see their topology. em1 and vlan1 interfaces are not active. The issue goes as it follows: I'm trying to establish communication between eth0 and bridge1 trying to ping from both sides, with unsuccessful results. From bridge1 towards eth0 the traffic looks fine through tcpdump, being the route: bridge1 -> vlan0 -> em0 -> eth0.100 -> eth0 However, once the packets attempt to do the route in different direction, they get stuck in bridge0, being the route: eth0 -> eth0.100 -> em0 -> bridge0 From my investigations seems that this setup is not supported by both FreeBSD implementations (8.3 and CURRENT), but I'd like to know if you can provide some insight about: - Why packets are forwarded from 'em0' to 'bridge0', and 'vlan0' is ignored. I'm aware that bridges introduce some changes in the packet routing, but it seems weird that being in promisc mode, 'em0' is not forwarding any package to 'vlan0'. - Why the packets are stuck in bridge0. I guess that because of the mechanism of the bridge, packets cannot be pushed back to the same channel they were received... and being 'em1' not active, 'bridge0' is sort of a dead end for the packets. I have some explanations for the second point, but the first one is puzzling me. I'd appreciate some comments about this issue. Thank you. -- Pozdrawiam, Pablo Ribalta Lorenzo From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 11:58:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D6945C4 for ; Tue, 9 Apr 2013 11:58:34 +0000 (UTC) (envelope-from prvs=18115ede16=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0E73F389 for ; Tue, 9 Apr 2013 11:58:33 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50003172461.msg for ; Tue, 09 Apr 2013 12:58:27 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 09 Apr 2013 12:58:27 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=18115ede16=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: Subject: Review of patch for raw packet source address selection under jails Date: Tue, 9 Apr 2013 12:58:33 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0E76_01CE3521.F1381360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:58:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0E76_01CE3521.F1381360 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Currently source address selection for raw packets under jails uses prison_get_ip4 in the INADDR_ANY case. This can cause an invalid source address to be used, including using addresses which are unusable e.g. down interfaces un-routable addresses etc. I suspect this is a hang over from when jails where essentially single IP. The attached patch switches to use full resolution for raw packets via in_pcbladdr, which fixes this problem in all of our testing. Is this the correct path to take? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_0E76_01CE3521.F1381360 Content-Type: application/octet-stream; name="jail-raw-srcaddr.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jail-raw-srcaddr.patch" Fix jailed raw sockets not setting the correct source address by=0A= calling in_pcbladdr instead of prison_get_ip4=0A= --- sys/netinet/in_pcb.h.orig 2013-04-05 16:59:33.005670964 +0000=0A= +++ sys/netinet/in_pcb.h 2013-04-05 17:00:24.725266747 +0000=0A= @@ -490,6 +490,8 @@=0A= struct ucred *, int);=0A= int in_pcbbind_setup(struct inpcb *, struct sockaddr *, in_addr_t *,=0A= u_short *, struct ucred *);=0A= +int in_pcbladdr(struct inpcb *, struct in_addr *, struct in_addr *,=0A= + struct ucred *);=0A= int in_pcbconnect(struct inpcb *, struct sockaddr *, struct ucred *);=0A= int in_pcbconnect_setup(struct inpcb *, struct sockaddr *, in_addr_t *,=0A= u_short *, in_addr_t *, u_short *, struct inpcb **,=0A= --- sys/netinet/in_pcb.c.orig 2013-04-05 16:59:28.252798648 +0000=0A= +++ sys/netinet/in_pcb.c 2013-04-05 16:59:38.888509732 +0000=0A= @@ -596,7 +596,7 @@=0A= * Do proper source address selection on an unbound socket in case=0A= * of connect. Take jails into account as well.=0A= */=0A= -static int=0A= +int=0A= in_pcbladdr(struct inpcb *inp, struct in_addr *faddr, struct in_addr = *laddr,=0A= struct ucred *cred)=0A= {=0A= --- sys/netinet/raw_ip.c.orig 2013-04-05 16:44:24.458314711 +0000=0A= +++ sys/netinet/raw_ip.c 2013-04-05 17:10:54.902524046 +0000=0A= @@ -442,16 +442,16 @@=0A= ip->ip_p =3D inp->inp_ip_p;=0A= ip->ip_len =3D m->m_pkthdr.len;=0A= ip->ip_src =3D inp->inp_laddr;=0A= + ip->ip_dst.s_addr =3D dst;=0A= if (jailed(inp->inp_cred)) {=0A= /*=0A= * prison_local_ip4() would be good enough but would=0A= * let a source of INADDR_ANY pass, which we do not=0A= - * want to see from jails. We do not go through the=0A= - * pain of in_pcbladdr() for raw sockets.=0A= + * want to see from jails.=0A= */=0A= if (ip->ip_src.s_addr =3D=3D INADDR_ANY)=0A= - error =3D prison_get_ip4(inp->inp_cred,=0A= - &ip->ip_src);=0A= + error =3D in_pcbladdr(inp, &ip->ip_dst, &ip->ip_src,=0A= + inp->inp_cred);=0A= else=0A= error =3D prison_local_ip4(inp->inp_cred,=0A= &ip->ip_src);=0A= @@ -461,7 +461,6 @@=0A= return (error);=0A= }=0A= }=0A= - ip->ip_dst.s_addr =3D dst;=0A= ip->ip_ttl =3D inp->inp_ip_ttl;=0A= } else {=0A= if (m->m_pkthdr.len > IP_MAXPACKET) {=0A= ------=_NextPart_000_0E76_01CE3521.F1381360-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 9 18:44:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD965D99 for ; Tue, 9 Apr 2013 18:44:48 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 7D40B1EA for ; Tue, 9 Apr 2013 18:44:48 +0000 (UTC) Received: (qmail 73191 invoked from network); 9 Apr 2013 18:44:40 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay00.pair.com with SMTP; 9 Apr 2013 18:44:40 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r39Iie5b062980; Tue, 9 Apr 2013 20:44:40 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r39Iid2W062979; Tue, 9 Apr 2013 20:44:39 +0200 (CEST) (envelope-from pho) Date: Tue, 9 Apr 2013 20:44:39 +0200 From: Peter Holm To: Andre Oppermann Subject: Re: panic in tcp_do_segment() Message-ID: <20130409184439.GA62925@x2.osted.lan> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> <20130409081652.GA50498@x2.osted.lan> <5163D2D2.2090407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5163D2D2.2090407@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net , Juan Mojica , Matt Miller , Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:44:48 -0000 On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote: > On 09.04.2013 10:16, Peter Holm wrote: > > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote: > >> On 05.04.2013 13:09, Matt Miller wrote: > >>> Hey Rick, > >>> > >>> I believe Juan and I have root caused this crash recently. The t_state = > >>> 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. > >>> > >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the > >>> socket and we should never enter tcp_do_segment() for this state. I think > >>> if you look in your corefile, you'll see the socket *doesn't* have this > >>> flag set in your case. > >>> > >>> 1043 /* > >>> 1044 * When the socket is accepting connections (the INPCB is in > >>> LISTEN > >>> 1045 * state) we look into the SYN cache if this is a new > >>> connection > >>> 1046 * attempt or the completion of a previous one. Because listen > >>> 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo lock > >>> will be > >>> 1048 * held in this case. > >>> 1049 */ > >>> 1050 if (so->so_options & SO_ACCEPTCONN) { > >>> 1051 struct in_conninfo inc; > >>> 1052 > >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so accepting > >>> but " > >>> 1054 "tp not listening", __func__)); > >>> ... > >>> 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, NULL); > >>> 1357 /* > >>> 1358 * Entry added to syncache and mbuf consumed. > >>> 1359 * Everything already unlocked by syncache_add(). > >>> 1360 */ > >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > >>> 1362 return; > >>> 1363 } > >>> ... > >>> 1384 /* > >>> 1385 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or > >>> later > >>> 1386 * state. tcp_do_segment() always consumes the mbuf chain, > >>> unlocks > >>> 1387 * the inpcb, and unlocks pcbinfo. > >>> 1388 */ > >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, > >>> ti_locked); > >>> > >>> I think this has to do with this patch in soclose() where SO_ACCEPTCONN is > >>> being turned off in soclose(). I suspect if you look at the other threads > >>> in your corefile, you'll see one at this point in soclose() operating on > >>> the same socket as the one in the tcp_do_segment() thread. > >>> > >>> http://svnweb.freebsd.org/base?view=revision&revision=243627 > >>> > >>> 817 /* > >>> 818 * Prevent new additions to the accept queues due > >>> 819 * to ACCEPT_LOCK races while we are draining them. > >>> 820 */ > >>> 821 so->so_options &= ~SO_ACCEPTCONN; > >>> 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != NULL) { > >>> 823 TAILQ_REMOVE(&so->so_incomp, sp, so_list); > >>> 824 so->so_incqlen--; > >>> 825 sp->so_qstate &= ~SQ_INCOMP; > >>> 826 sp->so_head = NULL; > >>> 827 ACCEPT_UNLOCK(); > >>> 828 soabort(sp); > >>> 829 ACCEPT_LOCK(); > >>> 830 } > >>> > >>> Juan had evaluated this code path and it seemed safe to just drop the > >>> packet in this case: > >>> > >>> + /* > >>> + * In closing down the socket, the SO_ACCEPTCONN flag is removed to > >>> + * prevent new connections from being established. This means that > >>> + * any frames in that were in the midst of being processed could > >>> + * make it here. Need to just drop the frame. > >>> + */ > >>> + if (TCPS_LISTEN == tp->t_state) { > >>> + TCPSTAT_INC(tcps_rcvwhileclosing); > >>> + goto drop; > >>> + } > >>> KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > >>> __func__)); > >>> > >>> Or, if there's someone more familiar with the locking in these paths, they > >>> may be able to come up with a way to restructure the locks and logic to > >>> close this window. > >> > >> Matt, Juan, > >> > >> excellent analysis. I don't see a better approach to handle this > >> under the current ACCEPT_LOCK model. > >> > >> Compared to your patch I'd like to handle this race earlier before > >> we hit tcp_do_segment(). > >> > >> Could you please review the attached patch which handles it right > >> after the SO_ACCEPTCONN / syncache check? > >> > >> -- > >> Andre > >> > >> Index: netinet/tcp_input.c > >> =================================================================== > >> --- netinet/tcp_input.c (revision 249253) > >> +++ netinet/tcp_input.c (working copy) > >> @@ -1351,6 +1351,16 @@ > >> */ > >> INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > >> return; > >> + } else if (tp->t_state == TCPS_LISTEN) { > >> + /* > >> + * When a listen socket is torn down the SO_ACCEPTCONN > >> + * flag is removed first while connections are drained > >> + * from the accept queue in a unlock/lock cycle of the > >> + * ACCEPT_LOCK, opening a race condition allowing a SYN > >> + * attempt go through unhandled. > >> + */ > >> + TCPSTAT_INC(tcps_rcvdwhileclosing); > >> + goto drop; > >> } > >> > >> #ifdef TCP_SIGNATURE > > > > I was able to reproduce the original "panic: tcp_do_segment: > > TCPS_LISTEN" with ease; see > > http://people.freebsd.org/~pho/stress/log/tcp.txt. > > > > With your patch (minus the TCPSTAT_INC) I got this "panic: Lock (rw) > > tcp locked @ netinet/tcp_input.c:1432." > > > > http://people.freebsd.org/~pho/stress/log/tcp2.txt > > Please replace the 'goto drop' with 'goto dropunlock' to fix the panic. > Yes, this seems to take care of the two problems reported. Tested for 5 hours without any repeats. - Peter From owner-freebsd-net@FreeBSD.ORG Wed Apr 10 14:32:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09FB2D1D for ; Wed, 10 Apr 2013 14:32:03 +0000 (UTC) (envelope-from md@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 7511C1D1 for ; Wed, 10 Apr 2013 14:32:02 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 297AAEBD4F for ; Wed, 10 Apr 2013 16:31:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id EvWTgsHlA9Ym for ; Wed, 10 Apr 2013 16:31:54 +0200 (CEST) Received: from [10.0.2.210] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 391BBEBD4D for ; Wed, 10 Apr 2013 16:31:54 +0200 (CEST) Message-ID: <51657801.1080700@semihalf.com> Date: Wed, 10 Apr 2013 16:32:33 +0200 From: Michal Dubiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Corrupted octets seen by tcpdump Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:32:03 -0000 Hi, I would like to ask you for some hints about where to look next and how could I debug the following issue: I have a FreeBSD host with two Ethernet interfaces and a Linux host with one interface, which connected each other as in the picture below: eth0.100 --- eth0 --------------- mge0 --- vlan0 \ \ bridge0 / / mge1 --- vlan1 On FreeBSD host: # ifconfig mge0: flags=8943 metric 0 mtu 1500 options=8000b ether 00:02:00:58:31:30 media: Ethernet autoselect (1000baseT ) status: active mge1: flags=8943 metric 0 mtu 1500 options=8000b ether 00:02:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 bridge0: flags=8843 metric 0 mtu 1500 ether 02:89:b3:33:d2:00 inet 192.168.126.6 netmask 0xffffff80 broadcast 192.168.126.127 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: mge1 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 20000 member: mge0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 20000 vlan0: flags=8843 metric 0 mtu 1500 ether 00:11:22:33:44:55 inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge0 vlan1: flags=8843 metric 0 mtu 1500 ether 00:02:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 The test is to ping from the remote Linux host the vlan0 interface (172.18.0.254). I intentionally changed the vlan0 MAC address to be different than it's parent: the mge0 device. I know it is not good configuration, but this allows me to reproduce the issue I'm asking here. The problem is that if I start sniffing packets (using tcpdump) on mge0 I observe correct ping requests, but on bridge0 interface I'm getting corruptions: # tcpdump -eni bridge0 15:34:15.624125 00:01:6c:ea:a1:70 > 00:11:22:33:44:55, ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, IP13 bad-hlen 8 I'm always seeing the same corruption (0xdb octed in the place where the first octet of IP header should be, plus one additional random octed right after it). This corrupts the IP version and header length fields. The interesting think is also that after those two bogus octets, the rest of the packet in the correct form appears. However, I instrumented the code of bridge interface (sys/net/if_bridge.c) and when I do printf() directly from the mbuf of the beginning bytes of the received packet I don't see any corruption there. I suspect there may be some problem with tcpdump or its integration with the stack. Have anyone had a similar problems/observations and does anybody have any hints on what can be causing this corruption and how to debug it further? I'm using FreeBSD 8.3 on ARM architecture. Thanks in advance for your response. Best regards, Michal From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 02:07:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69B01B69 for ; Thu, 11 Apr 2013 02:07:26 +0000 (UTC) (envelope-from Jean@femrice.com) Received: from mail.mail72.cn4e.com (mail.mail72.cn4e.com [218.107.207.72]) by mx1.freebsd.org (Postfix) with ESMTP id D7C178D3 for ; Thu, 11 Apr 2013 02:07:24 +0000 (UTC) Received: from WK (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP id 9BC61600231 for ; Thu, 11 Apr 2013 10:07:13 +0800 (CST) Received: from WK (unknown [123.235.38.82]) by mail.mail72.cn4e.com (Postfix) with ESMTPA for ; Thu, 11 Apr 2013 10:07:13 +0800 (CST) Date: Thu, 11 Apr 2013 10:07:10 +0800 From: Jean To: freebsd-net Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets X-Priority: 3 X-Message-Flag: =?gb2312?B?x+u72Li0?= X-GUID: 2895551B-2A2F-449E-96B1-B8FF7359B0D8 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201304111007086719791@femrice.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jean List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 02:07:26 -0000 SGVsbG8sDQoNCg0KSSBhbSBqZWFuIGFuZCB2ZXJ5IGdsYWQgdG8ga25vdyB5b3UgZnJvbSBHb29n bGUgd2Vic2l0ZSAuQ2hlY2tlZCB5b3VyIHdlYnNpdGUgYW5kIG1heWJlIHlvdXIgY3VzdG9tZXIg bmVlZCBvdXIgDQoNCnByb2R1Y3RzIHNvIFdyaXRlIHRvIHlvdSBhbmQgdGFsayBhYm91dCB3aGV0 aGVyIHdlIGNvdWxkIGNvb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gdGhlIGZ1cnRoZXIgLg0K DQoNCndlIGFyZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJu ZXQgTklDIENhcmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3Vy IA0KDQpGZW1yaWNlIGJyYW5kIC5DRSxGQyxST0hTLCBTdG9jaywgbGlmZXRpbWUgd2FycmFudHku VmVyeSBnb29kIHByaWNlIGluIHRoZSBtYXJrZXQuIA0KDQoNCndlIGFsc28gc3VwcGx5IFNGUCAs U0ZQKyxYRlAgYW5kIG90aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQoNCg0KVGhlIEZvbGxvd2luZyBv bmUgaXMgb3VyIG1haW5seSBOSUMgQ2FyZHM6DQoNCg0KRmliZXIgY2FyZHMgOg0KDQoNCjEuIFBD SSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVy IE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVy ICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoNCg0KMi4gUENJIEV4cHJlc3MgKHg0KSBEdWFsIFBv cnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxM QywgSW50ZWw4MjU3NkVCIENoaXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAw MkVGDQoNCg0KMy5QQ0kgRXhwcmVzcyh4NCkgICBEdWFsIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBO SUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MERCQ2hpcHNl dCBjb250cm9sbGVyICwgIFR5cGUgTnVtYmVyIDogMUcyREI1ODAtU0ZQDQoNCg0KNC4gUENJIEV4 cHJlc3MgKHg0KSBTaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciBO SUMgQ2FyZCAsU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcyRUkgQ2hpcHNldCBjb250cm9sbGVyICwg ICBUeXBlIE51bWJlciA6IDEwMDAxUEYNCg0KDQo1LiBQQ0kgRXhwcmVzcyAoeDEpIFNpbmdsZSBQ b3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAs TEMsIEludGVsODI1ODMgQ2hpcHNldCBjb250cm9sbGVyICwgICBUeXBlIE51bWJlciA6IDFHUEY1 ODMtU0ZQDQoNCg0KNi4gUENJIEV4cHJlc3MgKHg0KSBRdWFkIFBvcnQgR2lnYWJpdCBFdGhlcm5l dCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MEVCIENo aXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAwNFBGDQoNCg0KNy5QQ0kgRXhw cmVzcyAoeDgpIER1YWwgUG9ydCAxMEcgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJk ICxTRlAgU2xvdCAsTEMsIEludGVsODI1OTlFUyBDaGlwc2V0IGNvbnRyb2xsZXIgLCAgIFR5cGUg TnVtYmVyIDogMTBHMkJGLVNGUCsNCg0KDQo4LiAgUENJIEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQv U2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgLCBTRlAgU2xvdCAs TEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBqdXN0ICBUcmFuc21pc3NpdmUg IG5vDQogDQpyZWNlaXZlciBmdW5jdGlvbnMgVHlwZSBOdW1iZXIgOiAxRzJCRjU3MS1UWCAoTWFp bmx5IHVzZWQgaW4gVW5pLWRpcmVjdGlvbmFsIEdBUCApDQoNCg0KOS5QQ0kgRXhwcmVzcyh4NC8p IER1YWwgUG9ydC9TaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciAs IFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MUVCIENoaXBzZXQgY29udHJvbGxlciAsICBqdXN0IFJl Y2VpdmVyIG5vDQogDQp0cmFuc21pc3Npb24gZnVuY3Rpb25zIFR5cGUgTnVtYmVyIDogMUcyQkY1 NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQoNClBseiByZXBs eSB0byBtZSBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gb3VyIFByb2R1Y3RzIC4NCg0KSG9wZSB3 ZSBoYXZlIGNoYW5jZSB0byBjb29wZXJhdGUgd2l0aCBlYWNoIG90aGVyIGluIHRoZSBmdXJ0aGVy IC4NCg0KDQpJZiB5b3UgaGF2ZSBTa3lwZSBvciBNU04gSUQgaXMgbW9yZSBiZXR0ZXIgLE15IHNr eXBlIDogRHJlYW0tZmx5OTkNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KDQpKZWFuIGhlbmcNCg0KDQpG ZW1yaWNlIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4NCg0KDQpUZWw6MDA4Ni0xMC01MTI2 NjgwNy04MTMgDQoNCg0KTW9iaWxlOjAwODYtMTMwMDEwMjM2MTUNCg0KDQpGYXg6IDAwODYtMTAt NjI5NzkzNDMNCg0KDQpFbWFpbDogSmVhbkBmZW1yaWNlLmNvbSANCg0KDQpXZWJzaXRlczogaHR0 cDovL3d3dy5ldGhlcm5ldHNlcnZlcmFkYXB0ZXIuY29tLw0KICAgICAgICAgIHd3dy5mZW1yaWNl LmNvbSANCg0KDQpTa3lwZTogRHJlYW0tZmx5OTkNCg0KDQpNU046IERyZWFtLWZseTk5QEhvdG1h aWwuY29t From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 06:55:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3488E2A4 for ; Thu, 11 Apr 2013 06:55:02 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by mx1.freebsd.org (Postfix) with ESMTP id B7CD8352 for ; Thu, 11 Apr 2013 06:55:01 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id t11so1280353lbi.11 for ; Wed, 10 Apr 2013 23:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=UEFRo1DcoILhKYrBcADO8CYdV5fI1LR0UrO3MlM/ZIU=; b=lpH/JWO8d19IoDYWP2XrHOs5vogjKpd6SEJEdHTVWbU9h1aShBQDiqU7Z/jEfxiRVx xgO7+FMdbNDfYC6tWHT677SNDCLq7XfVuQDz1iM23R2jl5ZJ7l5+W0wkCtukn+uxMMi6 A9Zv5Res29GgvBrrHTn8EfM1JFNn64Baods0WpyD4hAxFkcO0zDcFa6fMw99RVoo4ArS ukju9yslXf4P615dIP7+XDl6FukEDd5uRazTWYo9QpzzEeGK74GlRJLIPOptJL1x/X58 MlakwzS8ct47k+xGu9wwqmVFnyfT+h5kL4at313gxZRP3gkWdxd5UA8k0AD9U8m/RAnY y1dA== X-Received: by 10.112.20.106 with SMTP id m10mr2686604lbe.8.1365663295118; Wed, 10 Apr 2013 23:54:55 -0700 (PDT) References: <51657801.1080700@semihalf.com> In-Reply-To: <51657801.1080700@semihalf.com> Mime-Version: 1.0 (1.0) From: Nikolay Denev Date: Thu, 11 Apr 2013 07:54:54 +0100 Message-ID: <-2382443979031863675@unknownmsgid> Subject: Re: Corrupted octets seen by tcpdump To: Michal Dubiel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 06:55:02 -0000 On 10.04.2013, at 15:32, Michal Dubiel wrote: > Hi, > > I would like to ask you for some hints about where to look next and how c= ould I debug the following issue: > > I have a FreeBSD host with two Ethernet interfaces and a Linux host with = one interface, which connected each other as in the picture below: > > eth0.100 --- eth0 --------------- mge0 --- vlan0 > \ > \ > bridge0 > / > / > mge1 --- vlan1 > > On FreeBSD host: > # ifconfig > mge0: flags=3D8943 metric= 0 mtu 1500 > options=3D8000b > ether 00:02:00:58:31:30 > media: Ethernet autoselect (1000baseT ) > status: active > mge1: flags=3D8943 metric= 0 mtu 1500 > options=3D8000b > ether 00:02:01:58:31:30 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D3 > bridge0: flags=3D8843 metric 0 mt= u 1500 > ether 02:89:b3:33:d2:00 > inet 192.168.126.6 netmask 0xffffff80 broadcast 192.168.126.127 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: mge1 flags=3D143 > ifmaxaddr 0 port 3 priority 128 path cost 20000 > member: mge0 flags=3D143 > ifmaxaddr 0 port 2 priority 128 path cost 20000 > vlan0: flags=3D8843 metric 0 mtu = 1500 > ether 00:11:22:33:44:55 > inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge0 > vlan1: flags=3D8843 metric 0 mtu = 1500 > ether 00:02:01:58:31:30 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge1 > > The test is to ping from the remote Linux host the vlan0 interface (172.1= 8.0.254). I intentionally changed the vlan0 MAC address to be different tha= n it's parent: the mge0 device. I know it is not good configuration, but th= is allows me to reproduce the issue I'm asking here. The problem is that if= I start sniffing packets (using tcpdump) on mge0 I observe correct ping re= quests, but on bridge0 interface I'm getting corruptions: > > # tcpdump -eni bridge0 > 15:34:15.624125 00:01:6c:ea:a1:70 > 00:11:22:33:44:55, ethertype 802.1Q (= 0x8100), length 104: vlan 100, p 0, ethertype IPv4, IP13 bad-hlen 8 > > I'm always seeing the same corruption (0xdb octed in the place where the = first octet of IP header should be, plus one additional random octed right = after it). This corrupts the IP version and header length fields. The inter= esting think is also that after those two bogus octets, the rest of the pac= ket in the correct form appears. However, I instrumented the code of bridge= interface (sys/net/if_bridge.c) and when I do printf() directly from the m= buf of the beginning bytes of the received packet I don't see any corruptio= n there. I suspect there may be some problem with tcpdump or its integratio= n with the stack. Have anyone had a similar problems/observations and does = anybody have any hints on what can be causing this corruption and how to de= bug it further? > > I'm using FreeBSD 8.3 on ARM architecture. Thanks in advance for your res= ponse. > > Best regards, > Michal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Do you still see this if you increase tcpdump's snaplen by adding the "-s0" option for example? From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 08:15:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58B8BCA5 for ; Thu, 11 Apr 2013 08:15:15 +0000 (UTC) (envelope-from Jean@femrice.com) Received: from mail.mail72.cn4e.com (mail.mail72.cn4e.com [218.107.207.72]) by mx1.freebsd.org (Postfix) with ESMTP id DA431996 for ; Thu, 11 Apr 2013 08:15:13 +0000 (UTC) Received: from WK (localhost.localdomain [127.0.0.1]) by mail.mail72.cn4e.com (Postfix) with SMTP id EA3E46001DA for ; Thu, 11 Apr 2013 16:15:09 +0800 (CST) Received: from WK (unknown [123.235.38.82]) by mail.mail72.cn4e.com (Postfix) with ESMTPA for ; Thu, 11 Apr 2013 16:15:09 +0800 (CST) Date: Thu, 11 Apr 2013 16:14:58 +0800 From: Jean To: freebsd-net Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets X-Priority: 3 X-Message-Flag: =?gb2312?B?x+u72Li0?= X-GUID: FB0D9DDD-5308-47C1-83CC-30AD8C559D54 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2013041116145510946350@femrice.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jean List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 08:15:15 -0000 SGVsbG8sDQoNCg0KSSBhbSBqZWFuIGFuZCB2ZXJ5IGdsYWQgdG8ga25vdyB5b3UgZnJvbSBHb29n bGUgd2Vic2l0ZSAuQ2hlY2tlZCB5b3VyIHdlYnNpdGUgYW5kIG1heWJlIHlvdXIgY3VzdG9tZXIg bmVlZCBvdXIgDQoNCnByb2R1Y3RzIHNvIFdyaXRlIHRvIHlvdSBhbmQgdGFsayBhYm91dCB3aGV0 aGVyIHdlIGNvdWxkIGNvb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gdGhlIGZ1cnRoZXIgLg0K DQoNCndlIGFyZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJu ZXQgTklDIENhcmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3Vy IA0KDQpGZW1yaWNlIGJyYW5kIC5DRSxGQyxST0hTLCBTdG9jaywgbGlmZXRpbWUgd2FycmFudHku VmVyeSBnb29kIHByaWNlIGluIHRoZSBtYXJrZXQuIA0KDQoNCndlIGFsc28gc3VwcGx5IFNGUCAs U0ZQKyxYRlAgYW5kIG90aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQoNCg0KVGhlIEZvbGxvd2luZyBv bmUgaXMgb3VyIG1haW5seSBOSUMgQ2FyZHM6DQoNCg0KRmliZXIgY2FyZHMgOg0KDQoNCjEuIFBD SSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVy IE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVy ICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoNCg0KMi4gUENJIEV4cHJlc3MgKHg0KSBEdWFsIFBv cnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxM QywgSW50ZWw4MjU3NkVCIENoaXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAw MkVGDQoNCg0KMy5QQ0kgRXhwcmVzcyh4NCkgICBEdWFsIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBO SUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MERCQ2hpcHNl dCBjb250cm9sbGVyICwgIFR5cGUgTnVtYmVyIDogMUcyREI1ODAtU0ZQDQoNCg0KNC4gUENJIEV4 cHJlc3MgKHg0KSBTaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciBO SUMgQ2FyZCAsU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcyRUkgQ2hpcHNldCBjb250cm9sbGVyICwg ICBUeXBlIE51bWJlciA6IDEwMDAxUEYNCg0KDQo1LiBQQ0kgRXhwcmVzcyAoeDEpIFNpbmdsZSBQ b3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAs TEMsIEludGVsODI1ODMgQ2hpcHNldCBjb250cm9sbGVyICwgICBUeXBlIE51bWJlciA6IDFHUEY1 ODMtU0ZQDQoNCg0KNi4gUENJIEV4cHJlc3MgKHg0KSBRdWFkIFBvcnQgR2lnYWJpdCBFdGhlcm5l dCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MEVCIENo aXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAwNFBGDQoNCg0KNy5QQ0kgRXhw cmVzcyAoeDgpIER1YWwgUG9ydCAxMEcgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJk ICxTRlAgU2xvdCAsTEMsIEludGVsODI1OTlFUyBDaGlwc2V0IGNvbnRyb2xsZXIgLCAgIFR5cGUg TnVtYmVyIDogMTBHMkJGLVNGUCsNCg0KDQo4LiAgUENJIEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQv U2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgLCBTRlAgU2xvdCAs TEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBqdXN0ICBUcmFuc21pc3NpdmUg IG5vDQogDQpyZWNlaXZlciBmdW5jdGlvbnMgVHlwZSBOdW1iZXIgOiAxRzJCRjU3MS1UWCAoTWFp bmx5IHVzZWQgaW4gVW5pLWRpcmVjdGlvbmFsIEdBUCApDQoNCg0KOS5QQ0kgRXhwcmVzcyh4NC8p IER1YWwgUG9ydC9TaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciAs IFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MUVCIENoaXBzZXQgY29udHJvbGxlciAsICBqdXN0IFJl Y2VpdmVyIG5vDQogDQp0cmFuc21pc3Npb24gZnVuY3Rpb25zIFR5cGUgTnVtYmVyIDogMUcyQkY1 NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQoNClBseiByZXBs eSB0byBtZSBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gb3VyIFByb2R1Y3RzIC4NCg0KSG9wZSB3 ZSBoYXZlIGNoYW5jZSB0byBjb29wZXJhdGUgd2l0aCBlYWNoIG90aGVyIGluIHRoZSBmdXJ0aGVy IC4NCg0KDQpJZiB5b3UgaGF2ZSBTa3lwZSBvciBNU04gSUQgaXMgbW9yZSBiZXR0ZXIgLE15IHNr eXBlIDogRHJlYW0tZmx5OTkNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KDQpKZWFuIGhlbmcNCg0KDQpG ZW1yaWNlIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4NCg0KDQpUZWw6MDA4Ni0xMC01MTI2 NjgwNy04MTMgDQoNCg0KTW9iaWxlOjAwODYtMTMwMDEwMjM2MTUNCg0KDQpGYXg6IDAwODYtMTAt NjI5NzkzNDMNCg0KDQpFbWFpbDogSmVhbkBmZW1yaWNlLmNvbSANCg0KDQpXZWJzaXRlczogaHR0 cDovL3d3dy5ldGhlcm5ldHNlcnZlcmFkYXB0ZXIuY29tLw0KICAgICAgICAgIHd3dy5mZW1yaWNl LmNvbSANCg0KDQpTa3lwZTogRHJlYW0tZmx5OTkNCg0KDQpNU046IERyZWFtLWZseTk5QEhvdG1h aWwuY29t From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 08:21:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B2BDFDB4 for ; Thu, 11 Apr 2013 08:21:53 +0000 (UTC) (envelope-from md@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 42BD79E9 for ; Thu, 11 Apr 2013 08:21:52 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 639D9EBDCE; Thu, 11 Apr 2013 10:21:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 1iGVmwyAsbKs; Thu, 11 Apr 2013 10:21:50 +0200 (CEST) Received: from [10.0.2.210] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 5B129EBD4F; Thu, 11 Apr 2013 10:21:50 +0200 (CEST) Message-ID: <516672C6.5010906@semihalf.com> Date: Thu, 11 Apr 2013 10:22:30 +0200 From: Michal Dubiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nikolay Denev Subject: Re: Corrupted octets seen by tcpdump References: <51657801.1080700@semihalf.com> <-2382443979031863675@unknownmsgid> In-Reply-To: <-2382443979031863675@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 08:21:53 -0000 On 11/04/13 08:54, Nikolay Denev wrote: > On 10.04.2013, at 15:32, Michal Dubiel wrote: > >> Hi, >> >> I would like to ask you for some hints about where to look next and how could I debug the following issue: >> >> I have a FreeBSD host with two Ethernet interfaces and a Linux host with one interface, which connected each other as in the picture below: >> >> eth0.100 --- eth0 --------------- mge0 --- vlan0 >> \ >> \ >> bridge0 >> / >> / >> mge1 --- vlan1 >> >> On FreeBSD host: >> # ifconfig >> mge0: flags=8943 metric 0 mtu 1500 >> options=8000b >> ether 00:02:00:58:31:30 >> media: Ethernet autoselect (1000baseT ) >> status: active >> mge1: flags=8943 metric 0 mtu 1500 >> options=8000b >> ether 00:02:01:58:31:30 >> media: Ethernet autoselect (1000baseT ) >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=3 >> bridge0: flags=8843 metric 0 mtu 1500 >> ether 02:89:b3:33:d2:00 >> inet 192.168.126.6 netmask 0xffffff80 broadcast 192.168.126.127 >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: mge1 flags=143 >> ifmaxaddr 0 port 3 priority 128 path cost 20000 >> member: mge0 flags=143 >> ifmaxaddr 0 port 2 priority 128 path cost 20000 >> vlan0: flags=8843 metric 0 mtu 1500 >> ether 00:11:22:33:44:55 >> inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> vlan: 100 parent interface: mge0 >> vlan1: flags=8843 metric 0 mtu 1500 >> ether 00:02:01:58:31:30 >> media: Ethernet autoselect (1000baseT ) >> status: active >> vlan: 100 parent interface: mge1 >> >> The test is to ping from the remote Linux host the vlan0 interface (172.18.0.254). I intentionally changed the vlan0 MAC address to be different than it's parent: the mge0 device. I know it is not good configuration, but this allows me to reproduce the issue I'm asking here. The problem is that if I start sniffing packets (using tcpdump) on mge0 I observe correct ping requests, but on bridge0 interface I'm getting corruptions: >> >> # tcpdump -eni bridge0 >> 15:34:15.624125 00:01:6c:ea:a1:70 > 00:11:22:33:44:55, ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, IP13 bad-hlen 8 >> >> I'm always seeing the same corruption (0xdb octed in the place where the first octet of IP header should be, plus one additional random octed right after it). This corrupts the IP version and header length fields. The interesting think is also that after those two bogus octets, the rest of the packet in the correct form appears. However, I instrumented the code of bridge interface (sys/net/if_bridge.c) and when I do printf() directly from the mbuf of the beginning bytes of the received packet I don't see any corruption there. I suspect there may be some problem with tcpdump or its integration with the stack. Have anyone had a similar problems/observations and does anybody have any hints on what can be causing this corruption and how to debug it further? >> >> I'm using FreeBSD 8.3 on ARM architecture. Thanks in advance for your response. >> >> Best regards, >> Michal >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > Do you still see this if you increase tcpdump's snaplen by adding the > "-s0" option for example? > Yes I'm still seeing this. Best regards, Michal From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 08:39:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 745FE36C for ; Thu, 11 Apr 2013 08:39:44 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 43B15AA1 for ; Thu, 11 Apr 2013 08:39:44 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so1720151ieb.31 for ; Thu, 11 Apr 2013 01:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=CUS8PjVgU8KDlBOpMfEKy85n1r3ouWmK+FkKKQHDA68=; b=VuY0SI9FTNg/pHVRvmzzML/6FYxEYSWo4r9hxhbjSGQ4dRp4NWFS27lu06pbUofiEv m6EqGT+b+5ZcHMSwvr+KrXMFKiVEBdwp/dblILnmwERdhwzxqn/dzqhhMFgHcSjayjtT stVTp1Y6/wjd1DF6f8M0oWVgAZyK+0iHc5lL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=CUS8PjVgU8KDlBOpMfEKy85n1r3ouWmK+FkKKQHDA68=; b=V6Sw+kye+udBqNK4GSbMoer0NecwcOCNELcXseC0mTRMAyV6eFymR6Av2hxQySE+OF LtO5vZMilhhUsTpPVnHAw90lZB6tKj5kznkZnM8TuO68sOx4XnIMvtlkJPpIQU9AwlPP CKFWcMEdAUAah/ECdvLHZ1kR0lfRENws/G/77FMeMA4SSmZPPWiK1nLUiaXoYiWIrVnI mvF1ug77rVHgqvhuXCfEqOe7mmSwswquxuG27nqZARwz1Bz3PYeQzeMiCPerg0d/6yDB R20VFJ/dBM8yWeOWI7amZLsVT0EN5AQ2M5Ri2CkugXdaTOm9u8usXZFDjFytkxwKZW0T nfjQ== X-Received: by 10.50.160.201 with SMTP id xm9mr3816289igb.101.1365669583848; Thu, 11 Apr 2013 01:39:43 -0700 (PDT) Received: from [192.168.30.77] (24-236-152-143.dhcp.aldl.mi.charter.com. [24.236.152.143]) by mx.google.com with ESMTPS id hi4sm1817081igc.6.2013.04.11.01.39.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 01:39:42 -0700 (PDT) References: <2013041116145510946350@femrice.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2013041116145510946350@femrice.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Jason Hellenthal Subject: Re: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets Date: Thu, 11 Apr 2013 04:39:39 -0400 To: Jean X-Gm-Message-State: ALoCoQnPkZx4fut/Yt94RU9A42Va/3uzHUgUT5Q4FVAz3o8vrjCIzSkANL41TiCD3kOe6xIBrSHK Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 08:39:44 -0000 You have already written to this list earlier. Give it up. --=20 Jason Hellenthal JJH448-ARIN -(^2(N-1)) On Apr 11, 2013, at 4:14, Jean wrote: > Hello, >=20 >=20 > I am jean and very glad to know you from Google website .Checked your webs= ite and maybe your customer need our=20 >=20 > products so Write to you and talk about whether we could cooperate with ea= ch other in the further . >=20 >=20 > we are the manufacturer of PCI Express 1G &10G Ethernet NIC Card(Server Ad= apter NIC Cards),Intel chipsets, Our=20 >=20 > Femrice brand .CE,FC,ROHS, Stock, lifetime warranty.Very good price in the= market.=20 >=20 >=20 > we also supply SFP ,SFP+,XFP and other special modules . >=20 >=20 > The Following one is our mainly NIC Cards: >=20 >=20 > Fiber cards : >=20 >=20 > 1. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card , S= FP Slot ,LC, Intel82571EB Chipset controller , Type Number : 10002PF >=20 >=20 > 2. PCI Express (x4) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card ,S= FP Slot ,LC, Intel82576EB Chipset controller , Type Number : 10002EF >=20 >=20 > 3.PCI Express(x4) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card ,S= FP Slot ,LC, Intel82580DBChipset controller , Type Number : 1G2DB580-SFP >=20 >=20 > 4. PCI Express (x4) Single Port Gigabit Ethernet NIC Card, Fiber NIC Card ,= SFP Slot ,LC, Intel82572EI Chipset controller , Type Number : 10001PF >=20 >=20 > 5. PCI Express (x1) Single Port Gigabit Ethernet NIC Card, Fiber NIC Card ,= SFP Slot ,LC, Intel82583 Chipset controller , Type Number : 1GPF583-SFP >=20 >=20 > 6. PCI Express (x4) Quad Port Gigabit Ethernet NIC Card, Fiber NIC Card ,S= FP Slot ,LC, Intel82580EB Chipset controller , Type Number : 10004PF >=20 >=20 > 7.PCI Express (x8) Dual Port 10G Ethernet NIC Card, Fiber NIC Card ,SFP Sl= ot ,LC, Intel82599ES Chipset controller , Type Number : 10G2BF-SFP+ >=20 >=20 > 8. PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card, Fibe= r , SFP Slot ,LC, Intel82571EB Chipset controller , just Transmissive no >=20 > receiver functions Type Number : 1G2BF571-TX (Mainly used in Uni-direction= al GAP ) >=20 >=20 > 9.PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card, Fiber ,= SFP Slot ,LC, Intel82571EB Chipset controller , just Receiver no >=20 > transmission functions Type Number : 1G2BF571-RX (Mainly used in Uni-direc= tional GAP ) >=20 >=20 > Plz reply to me if you are interested in our Products . >=20 > Hope we have chance to cooperate with each other in the further . >=20 >=20 > If you have Skype or MSN ID is more better ,My skype : Dream-fly99 >=20 >=20 > Best Regards >=20 >=20 > Jean heng >=20 >=20 > Femrice (China) Technology Co., Ltd. >=20 >=20 > Tel:0086-10-51266807-813=20 >=20 >=20 > Mobile:0086-13001023615 >=20 >=20 > Fax: 0086-10-62979343 >=20 >=20 > Email: Jean@femrice.com=20 >=20 >=20 > Websites: http://www.ethernetserveradapter.com/ > www.femrice.com=20 >=20 >=20 > Skype: Dream-fly99 >=20 >=20 > MSN: Dream-fly99@Hotmail.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 14:58:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64F867C6 for ; Thu, 11 Apr 2013 14:58:22 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by mx1.freebsd.org (Postfix) with ESMTP id 78829FAA for ; Thu, 11 Apr 2013 14:58:21 +0000 (UTC) Received: from [98.138.90.57] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 Received: from [98.138.226.161] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 11 Apr 2013 14:58:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 40162.61170.bm@omp1062.mail.ne1.yahoo.com Received: (qmail 43033 invoked by uid 60001); 11 Apr 2013 14:58:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365692294; bh=eAG9z3fVE7tFDpVN2+m5NqWUWf5BvojkCFve1U9n+vc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=0EaVu9K3NDdSeszRftH3CwJLgpZQy/Ethk/9na/FcnwfFveIhT+x7BhbLkNApRe8lVbzNtn6SNOcsp5zDs3dxwws/rTXMm0ONlBbfF866G7xG3hKJtO+aWp6xvjrV36hfpSrVXDOcrc+8jWMYZJ5Bpbq8POeJV39CTvBav3Wp/4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=wL19KokErFBYTq9RuAnux+aAcF612AC/sqR0T7h55TrlQ9btavPA0s8eEPMY/b8kXlHpf1QCpApQIxH34BqZj+TPCTum6vwkw5spC7FA5duOAL2AEu5n/XBL/T4mTTicbRqKtfwr1fa81Ld9ZCb8Tfi9UTmoIj9Wd2kUNvEG0uI=; X-YMail-OSG: u.kcfxcVM1krWEUuZrPhXgSt1OjJ4NtY05MWnqbGSqUQSZb IT_tGfuq3lO3zHsu1ZRVP.CcrenZXbpbxNpV8xHqVxbXz1GKVgLfGZGrPZ_a kQ.zzayokRpDX9suQBZ9NynXvzpWSpt5KlihoKVjLEgWgbLaqJyrTEqD57VF KhNM2mgeDYKVLEEyK8xBypO9KSQqS33mwOTjSy1sPCYMuZ13B6vT28XB4HV6 .8q7QjDtyxjiIjtzc7b90d7psWiwuBKBW1jakONBkGiI8MM8VRXHev5oRIxm A90vFAM.Lg9_dXJjVGszDVQAWxrwpMpUiHyuDDQRFibY.5cIzJjKsgdlu11n 4ZKUMemjEDkBjtVdtdEiB5WNwKU2vxIm.H9HrOQ_59fC75vEARcZKf37j_GS z2tjqyWI2oG7PZRkuqS_EfiBiNoyouh5IHpQ3wkN2UGUqhfTFVvDxgc3aBG1 DSeeNvJPr0YE- Received: from [98.203.118.124] by web125801.mail.ne1.yahoo.com via HTTP; Thu, 11 Apr 2013 07:58:14 PDT X-Rocket-MIMEInfo: 002.001, SW0gd29ya2luZyBvbiBhIHNpbXBsZSBwcm9qZWN0IHRoYXQgc2hhcmVzIGEgbWVtb3J5IHNlZ21lbnQgYmV0d2VlbiBhIHVzZXIgcHJvY2Vzc2FuZCBhIGtlcm5lbCBtb2R1bGUuIEknbSBoYXZpbmcgc29tZSBwcm9ibGVtcyB3aXRoIHNobV9tYXAgYW5kIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0b8KgYmUgbXVjaCBpbmZvIG9uIGl0Lg0KSW0gbm90IHN1cmUgd2hhdCBoYXBwZW5lZCB0byB0aGUgbWVtb3J5IHdoZW4gdGhlIHVzZXIgcHJvY2VzcyB0aGF0IGNyZWF0ZXMgaXTCoHRlcm1pbmF0ZXMuIMKgSSBoYXZlIHMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.7 YahooMailWebService/0.8.140.532 Message-ID: <1365692294.23098.YahooMailClassic@web125801.mail.ne1.yahoo.com> Date: Thu, 11 Apr 2013 07:58:14 -0700 (PDT) From: Laurie Jennings Subject: shm_map questions To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:58:22 -0000 Im working on a simple project that shares a memory segment between a user = processand a kernel module. I'm having some problems with shm_map and there= doesn't seem to=A0be much info on it. Im not sure what happened to the memory when the user process that creates = it=A0terminates. =A0I have some questions. 1) Does the kernel mapping keep the segment from being garbage collected wh= en the=A0use process that creates it terminated? I've experienced shm_unmap= () panic when tryingto unmap a segment scenario: =A0 User process Maps SegmentKernel maps it =A0with shm_map()User Process Termi= natesKernel tries to shm_unmap() and it panics. 2) Is there a way for the kernel process to know when the user process has = goneaway? A ref count? 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or = doesit get garbage collected when the creating user process terminates? 4) When using a named segment, can the kernel "reuse" a mapping for a new u= serprocess? Example: User process creates shm segment with path /fooKernel Maps shm segment with= shm_map()User process terminates.User process runs again, opening segment = /foo Does the kernel need to re-map, or is the original mapping valid? Thanks!Laurie From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 19:00:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9854D0A for ; Thu, 11 Apr 2013 19:00:39 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mx1.freebsd.org (Postfix) with ESMTP id 72FAB1361 for ; Thu, 11 Apr 2013 19:00:39 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j8so467759qah.5 for ; Thu, 11 Apr 2013 12:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=Ml3nZa9X4THOOGWN2CHzDSh0+U0pfve3aF1KpLOUeJY=; b=d7k4sdp0vUzTiv5Jbq3gKCVNWH90V1KMi6sJ/EWCIlljEclol9/wV4EJkYB/d3kOb7 e3OdkHOG5WCgjyDDTTWhGO59wIeV/+uu3q2A6jdutclgLBMPboKSNdftF/In+labp+DR 5dGYFinpJD+CsSsuDwAF505WjUj9ZiirAq2IFKrZAugCtQhDF1GTAg41sz4xQjqQux24 cCfNOi7MNpktHgKpAtEmZ2a6YqVLCGRALPStTsKr2HBHO6u//nlfvbwrJu/aOHL4JYlc MaJaoO6xgrz3AolLH828utUKsovSgXUouFJasfwUe7CqWYF/L/pY9Zb0XTXW2fJvYLff TY7w== X-Received: by 10.49.106.40 with SMTP id gr8mr8080767qeb.42.1365706833457; Thu, 11 Apr 2013 12:00:33 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.49.12.242 with HTTP; Thu, 11 Apr 2013 11:59:52 -0700 (PDT) From: Matt Miller Date: Thu, 11 Apr 2013 14:59:52 -0400 X-Google-Sender-Auth: aIVOnBjqgaW3W__v3ZLa6iIPmtg Message-ID: Subject: RFC 3042 Implementation To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:00:39 -0000 In some of our tests, we noticed some duplicate pure ACKs (not window updates), most of which the duplicates were coming from this tcp_output() call in tcp_do_segment() (line 2534): 2508 } else if (V_tcp_do_rfc3042) { 2509 cc_ack_received(tp, th, CC_DUPACK); 2510 u_long oldcwnd = tp->snd_cwnd; 2511 tcp_seq oldsndmax = tp->snd_max; 2512 u_int sent; 2513 2514 KASSERT(tp->t_dupacks == 1 || 2515 tp->t_dupacks == 2, 2516 ("%s: dupacks not 1 or 2", 2517 __func__)); 2518 if (tp->t_dupacks == 1) 2519 tp->snd_limited = 0; 2520 tp->snd_cwnd = 2521 (tp->snd_nxt - tp->snd_una) + 2522 (tp->t_dupacks - tp->snd_limited) * 2523 tp->t_maxseg; 2524 if ((thflags & TH_FIN) && 2525 (TCPS_HAVERCVDFIN(tp->t_state) == 0)) { 2526 /* 2527 * If its a fin we need to process 2528 * it to avoid a race where both 2529 * sides enter FIN-WAIT and send FIN|ACK 2530 * at the same time. 2531 */ 2532 break; 2533 } 2534 (void) tcp_output(tp); I added some instrumentation here to count how many time the following is zero prior to calling tcp_output(): so->so_snd.sb_cc - ((tp->snd_nxt - tp->snd_una) And, in our tests, it was like 97% of the time. It looks like the intent of the RFC is to only send one or two unsent data segments here, not pure ACKs. And this subsequent standard seems to clarify that new data should be available for transmission: http://tools.ietf.org/html/rfc5681 On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS, and that new data is available for transmission. So, this is a detailed way of asking: do we need a check here to make sure there is new data to send prior to calling tcp_output()? Thanks, Matt From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 19:42:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 358C683D; Thu, 11 Apr 2013 19:42:02 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF4915D3; Thu, 11 Apr 2013 19:42:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3BJg1Pi085645; Thu, 11 Apr 2013 19:42:01 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3BJg1Eh085644; Thu, 11 Apr 2013 19:42:01 GMT (envelope-from glebius) Date: Thu, 11 Apr 2013 19:42:01 GMT Message-Id: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> To: eugene@zhegan.in, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Subject: Re: kern/165903: mbuf leak X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:42:02 -0000 Synopsis: mbuf leak State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Thu Apr 11 19:40:46 UTC 2013 State-Changed-Why: Submitter reports, that problem can't be reproduced on 10.0-CURRENT http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073077.html http://www.freebsd.org/cgi/query-pr.cgi?pr=165903 From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 19:45:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94B04908 for ; Thu, 11 Apr 2013 19:45:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F01D915F9 for ; Thu, 11 Apr 2013 19:45:56 +0000 (UTC) Received: (qmail 71924 invoked from network); 11 Apr 2013 20:52:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2013 20:52:59 -0000 Message-ID: <516712EE.8010708@freebsd.org> Date: Thu, 11 Apr 2013 21:45:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Matt Miller Subject: Re: RFC 3042 Implementation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:45:57 -0000 On 11.04.2013 20:59, Matt Miller wrote: > In some of our tests, we noticed some duplicate pure ACKs (not window > updates), most of which the duplicates were coming from this tcp_output() > call in tcp_do_segment() (line 2534): > > 2508 } else if (V_tcp_do_rfc3042) { > 2509 cc_ack_received(tp, th, > CC_DUPACK); > 2510 u_long oldcwnd = tp->snd_cwnd; > 2511 tcp_seq oldsndmax = > tp->snd_max; > 2512 u_int sent; > 2513 > 2514 KASSERT(tp->t_dupacks == 1 || > 2515 tp->t_dupacks == 2, > 2516 ("%s: dupacks not 1 or 2", > 2517 __func__)); > 2518 if (tp->t_dupacks == 1) > 2519 tp->snd_limited = 0; > 2520 tp->snd_cwnd = > 2521 (tp->snd_nxt - > tp->snd_una) + > 2522 (tp->t_dupacks - > tp->snd_limited) * > 2523 tp->t_maxseg; > 2524 if ((thflags & TH_FIN) && > 2525 > (TCPS_HAVERCVDFIN(tp->t_state) == 0)) { > 2526 /* > 2527 * If its a fin we > need to process > 2528 * it to avoid a race > where both > 2529 * sides enter > FIN-WAIT and send FIN|ACK > 2530 * at the same time. > 2531 */ > 2532 break; > 2533 } > 2534 (void) tcp_output(tp); > > I added some instrumentation here to count how many time the following is > zero prior to calling tcp_output(): > > so->so_snd.sb_cc - ((tp->snd_nxt - tp->snd_una) > > And, in our tests, it was like 97% of the time. > > It looks like the intent of the RFC is to only send one or two unsent data > segments here, not pure ACKs. And this subsequent standard seems to > clarify that new data should be available for transmission: > > http://tools.ietf.org/html/rfc5681 > > > On the first and second duplicate ACKs received at a sender, a > TCP SHOULD send a segment of previously unsent data per [RFC3042] > provided that the receiver's advertised window allows, the total > FlightSize would remain less than or equal to cwnd plus 2*SMSS, > and that new data is available for transmission. > > > So, this is a detailed way of asking: do we need a check here to make sure > there is new data to send prior to calling tcp_output()? Yes. Based on your input the attached patch should fix it (untested). -- Andre Index: tcp_input.c =================================================================== --- tcp_input.c (revision 249375) +++ tcp_input.c (working copy) @@ -2564,6 +2564,7 @@ u_long oldcwnd = tp->snd_cwnd; tcp_seq oldsndmax = tp->snd_max; u_int sent; + int avail; KASSERT(tp->t_dupacks == 1 || tp->t_dupacks == 2, @@ -2585,7 +2586,17 @@ */ break; } - (void) tcp_output(tp); + /* + * Only call tcp_output when there + * is new data available to be sent. + * Otherwise we send pure ACKs. + */ + SOCKBUF_LOCK(&so->so_snd); + avail = so->so_snd.sb_cc - + (tp->snd_nxt - tp->snd_una); + SOCKBUF_UNLOCK(&so->so_snd); + if (avail > 0) + (void) tcp_output(tp); sent = tp->snd_max - oldsndmax; if (sent > tp->t_maxseg) { KASSERT((tp->t_dupacks == 2 && From owner-freebsd-net@FreeBSD.ORG Thu Apr 11 20:18:08 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D84E9828; Thu, 11 Apr 2013 20:18:08 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFC917C4; Thu, 11 Apr 2013 20:18:06 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3BKI5fG072030; Fri, 12 Apr 2013 00:18:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3BKI5kX072029; Fri, 12 Apr 2013 00:18:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 12 Apr 2013 00:18:05 +0400 From: Gleb Smirnoff To: net@FreeBSD.org, current@FreeBSD.org Subject: ipfilter(4) needs maintainer Message-ID: <20130411201805.GD76816@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:18:08 -0000 Hello, here is brief status on ipfilter(4) packet filtering facility, written by Darren Reed, that is shipped with FreeBSD kernel. o The version of the software is v4.1.28. The license is BSD, .. erm the license is very close to BSD, but with some additions, most notable is: > The licence and distribution terms for any publically available version or > derivative of this code cannot be changed. i.e. this code cannot simply be > copied, in part or in whole, and put under another distribution licence > [including the GNU Public Licence.] The version we have is v4.1.28, it was released 16 October 2007. Suprisingly, the author has switched ipfilter license to GPL. :) The last release under BSD license was v4.1.34, released 11 MArch 2010. The author is now working on v5, licensed under GPL. o There are 29 open bug reports tagged with [ipfilter] in GNATS. Actually this is not a lot, since there 95 closed PRs with this tag. Anyway, these 29 need care. o Apart from filed PRs, there is knowledge that ipfilter(4) isn't compatible with VIMAGE. o ipfilter(4) uses old outdated kernel APIs that we want to cleanse away from the kernel. And we don't have responsive users, willing to test patches. For example, this request for testing wasn't answered by anyone: http://lists.freebsd.org/pipermail/freebsd-net/2012-August/033139.html Due to license change and inactivity of the author in our tree and GNATS, there is clear evidence that author do not plan to update or take care of ipfilter in our source tree. Thus, ipfilter(4) should be assigned status of our code, that should be taken care of ourselves. This means it needs maintainer, and this email is a call for one. Any takers? Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. P.S. The project homepage: http://coombs.anu.edu.au/~avalon/ -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 05:28:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 566FA440 for ; Fri, 12 Apr 2013 05:28:09 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id F1BF0FF5 for ; Fri, 12 Apr 2013 05:28:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r3C5RrBb018995; Fri, 12 Apr 2013 12:27:54 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <51679B54.2060908@rdtc.ru> Date: Fri, 12 Apr 2013 12:27:48 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Karl Denninger Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? References: <516739C9.4080902@denninger.net> In-Reply-To: <516739C9.4080902@denninger.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 05:28:09 -0000 12.04.2013 05:31, Karl Denninger ÐÉÛÅÔ: > Is there a "cookbook" for setting this up? There are examples for > setting up a tunnel between two fixed-address networks (e.g. a remote > LAN that needs to be "integrated" with a central LAN over IPSec but I > can't find anything addressing the other situation -- remote user(s) > where the connecting IPs are not known in advance, such as a person with > a laptop or smartphone in a random hotel. > > (And is there a better list for this in the freebsd-* paradigm for the > question?) Moving to freebsd-net@ You'll need to install the port security/ipsec-tools for IKE protocol support. This port contains racoon daemon, here is sample racoon.conf: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; log debug; padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listening on { isakmp X.X.X.X [500]; isakmp Y.Y.Y.Y [500]; # isakmp_natt Z.Z.Z.Z [4500]; adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0600; } remote anonymous # just template { exchange_mode aggressive,main,base; doi ipsec_doi; situation identity_only; my_identifier fqdn "mydomain.net"; verify_identifier on; mode_cfg off; lifetime time 1 hour; ike_frag on; passive on; proposal_check obey; generate_policy unique; # script "/usr/local/etc/racoon/phase1" phase1_up; # script "/usr/local/etc/racoon/phase1" phase1_down; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 12 hour; dh_group 1; } proposal { encryption_algorithm aes 256; hash_algorithm sha1; authentication_method pre_shared_key; lifetime time 1 hour; dh_group 1; } } sainfo anonymous { pfs_group 1; lifetime time 1 hour; encryption_algorithm aes,3des,des; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate; } From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 08:40:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00F351AA for ; Fri, 12 Apr 2013 08:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CD3821733 for ; Fri, 12 Apr 2013 08:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3C8e1us038265 for ; Fri, 12 Apr 2013 08:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3C8e1Sa038264; Fri, 12 Apr 2013 08:40:01 GMT (envelope-from gnats) Date: Fri, 12 Apr 2013 08:40:01 GMT Message-Id: <201304120840.r3C8e1Sa038264@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Johan Broman Subject: Re: kern/170081: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Johan Broman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 08:40:02 -0000 The following reply was made to PR kern/170081; it has been noted by GNATS. From: Johan Broman To: bug-followup@FreeBSD.org, h.skuhra@gmail.com Cc: Subject: Re: kern/170081: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0 Date: Fri, 12 Apr 2013 10:30:50 +0200 --001a11c299667b887504da25b87f Content-Type: text/plain; charset=ISO-8859-1 Hi! Getting the exact same problem. No network traffic to my jails. # uname -a FreeBSD nexus 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Here's part of my pf.cf file -- snip-- ext_if="fxp0" int_if="bge0" jail_if="lo1" ext_ip="192.168.1.2" # behind a firewall int_ip="192.168.0.1" jail_net="10.0.0.0/24" scrub in all nat on $ext_if from !($ext_if) -> $ext_ip --snip -- I removed rxcsum from fxp0 using: # ifconfig fxp0 -rxcsum Now everything works great and jails get network traffic. Let me know if you need more detailed information. Thanks Johan --001a11c299667b887504da25b87f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

Getting the exact same problem.= No network traffic to my jails.

# uname -a

FreeBSD nexus 9.1= -RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec=A0 4 09:23:10 UTC 2012=A0= =A0=A0=A0 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=A0 amd6= 4

Here's part of my pf= .cf file

-- snip--

ext_if=3D"f= xp0"
int_if=3D"bge0"
jail_if=3D"lo1"
ext_= ip=3D"192.168.1.2" # behind a firewall
int_ip=3D"192.168.0.1"
jail_net=3D"10.0.0.0/24"


scrub in all

nat on $ext_i= f from !($ext_if) -> $ext_ip

--snip --

I removed rxcsum from fxp0 using:

# ifconfig fxp0 -rxcsum

Now everything works great and jails get network traffic.

<= /div>
Let me know if you need more detailed information.

Thanks
Johan
--001a11c299667b887504da25b87f-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 11:46:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53176A63; Fri, 12 Apr 2013 11:46:13 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0552C192; Fri, 12 Apr 2013 11:46:12 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w15so2029775vbb.23 for ; Fri, 12 Apr 2013 04:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=7qqFYig4fG+534iSTqfHsqpwHtt/C2WBrZ0i8B6voVY=; b=RSd+JY26JgA6t/0yDZ7AGG9o679pZlfgCk0fPIb9VAV4BG8/+p6cC4z8QM6x0eUdwM 2Z6/4THn1PONmr2OfaCF62N62WexwBBUP8tjVTe1K/A6PKt+nZj8198xN11iDviqUO8E HXejX4XD/dvwCfVVqw7oqFN6i46Wc2UBskX8ujX6FXdfYd4FAVcChrAaGAG7LZALSHaf gLjXulZSIw3DqXNkHh3Eo/gyEjWri0qNRkVe8ASAES8JWfPQTRvQtqiVEYdfLc/scefM Ug/TzaX6d8eh93gvzKtwXSY4gSJrGGORCrdOLd7Tc2e9M877kykFEahPjv1foF1XQZSr oqkg== X-Received: by 10.220.65.1 with SMTP id g1mr8133093vci.63.1365767172520; Fri, 12 Apr 2013 04:46:12 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.59.9.103 with HTTP; Fri, 12 Apr 2013 04:45:51 -0700 (PDT) In-Reply-To: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> References: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 12 Apr 2013 13:45:51 +0200 X-Google-Sender-Auth: -NzL_XzPelH0F1UM8f7WRJsRchI Message-ID: Subject: Re: kern/165903: mbuf leak To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , eugene@zhegan.in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:46:13 -0000 Hi, PR closed too soon ? All of our firewalls just migrated to 9.0 firewall (carp + pfsync) hit memory leak problem. Here is some output: Mem: 17M Active, 15M Inact, 1709M Wired, 1392K Cache, 143M Buf, 229M Free => 1709M Wired just for a firewall ? On other machine: # netstat -m 2188812/1278/2190090 mbufs in use (current/cache/total) 6132/1762/7894/25600 mbuf clusters in use (current/cache/total/max) 6132/1036 mbuf+clusters out of packet secondary zone in use (current/cache) 0/54/54/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 559467K/4059K/563526K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 11:54:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1966C5C for ; Fri, 12 Apr 2013 11:54:54 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 55481217 for ; Fri, 12 Apr 2013 11:54:53 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3CBsh19077420; Fri, 12 Apr 2013 15:54:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3CBshBE077419; Fri, 12 Apr 2013 15:54:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 12 Apr 2013 15:54:43 +0400 From: Gleb Smirnoff To: Olivier Cochard-Labb? Subject: Re: kern/165903: mbuf leak Message-ID: <20130412115443.GU76816@glebius.int.ru> References: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" , eugene@zhegan.in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:54:54 -0000 On Fri, Apr 12, 2013 at 01:45:51PM +0200, Olivier Cochard-Labb? wrote: O> PR closed too soon ? It isn't closed, it is in patched state. This means that problem is considered solve in the head branch, but not in any stable branch. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 14:13:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA0369D1; Fri, 12 Apr 2013 14:13:39 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 794979E0; Fri, 12 Apr 2013 14:13:39 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id w15so2190169vbf.32 for ; Fri, 12 Apr 2013 07:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=04sjRyEJcS8165JtLca70fZHjpD1dfABIW5iyJVUK9E=; b=IIOlSgyzCyl6EzOnGJX1bHkh61w4XT7uHpZivHA3JjcjbE3ppALXBk9MLoWwrsvKdU YGjaPoSg5eoKJExWLuAdxygl9VQCFK8wPVLNy9ePD149z9e05I3qSZ+rH3zn4+jFQ6vn 5oqCRHqWA9V4ffmvCbnwoNpQf6DsHdIEZ7D9m1/yL33FDDGNcX4geOUO85xML4RKOlim tAcwqQMrOqbcBcOX4Cz4Yl7FOWkDz3H75ENS9fZ9huohjemeyAGb0Bq4u0bqvQglVmIo hBS3pfadQfHmGn0DJrs/OxVtaxXJD9aI2ZGea1z3cGcTtQ/JTqBv5FI7XXwKX1mL7eDb BUiw== X-Received: by 10.52.28.196 with SMTP id d4mr7277359vdh.56.1365776018781; Fri, 12 Apr 2013 07:13:38 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.59.9.103 with HTTP; Fri, 12 Apr 2013 07:13:18 -0700 (PDT) In-Reply-To: <20130412115443.GU76816@glebius.int.ru> References: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> <20130412115443.GU76816@glebius.int.ru> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 12 Apr 2013 16:13:18 +0200 X-Google-Sender-Auth: P8wOli5Nervl7RVpoGjPQ1Tis5A Message-ID: Subject: Re: kern/165903: mbuf leak To: Gleb Smirnoff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:13:39 -0000 On Fri, Apr 12, 2013 at 1:54 PM, Gleb Smirnoff wrote: > On Fri, Apr 12, 2013 at 01:45:51PM +0200, Olivier Cochard-Labb? wrote: > O> PR closed too soon ? > > It isn't closed, it is in patched state. This means that problem > is considered solve in the head branch, but not in any stable branch. Ok, thanks for this clarification ! More information of my mbuf leak problem now: I've got a firewall (FreeBSD 9.0, nanobsd with pf+pfsync, no tunning) in my= lab. We did some bench tests some weeks ago: During this time, lot's of traffic pass this firewall. But since, we didn't run bench lab. currently there are few pf states: # uptime 3:03PM up 64 days, 23:11, 1 user, load averages: 0.24, 0.28, 0.27 #pfctl -si Status: Enabled for 65 days 00:10:32 Debug: Urgent State Table Total Rate current entries 11 searches 48558531 8.6/s inserts 13483557 2.4/s removals 13483546 2.4/s Counters match 12875392 2.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 294 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s BUT we have a problem: # top -b last pid: 34882; load averages: 0.31, 0.31, 0.30 up 65+00:03:03 15:= 56:11 40 processes: 2 running, 38 sleeping Mem: 31M Active, 42M Inact, 922M Wired, 1656K Cache, 90M Buf, 14G Free =3D> 922M of Wired RAM, it's a lot's for a simple firewall. Checking the mbuf : # netstat -m 2188812/1278/2190090 mbufs in use (current/cache/total) 6132/1762/7894/25600 mbuf clusters in use (current/cache/total/max) 6132/1036 mbuf+clusters out of packet secondary zone in use (current/cache) 0/54/54/12800 4k (page size) jumbo clusters in use (current/cache/total/max= ) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 559467K/4059K/563526K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines =3D> mbufs used are quiet lot=85 but there is only very few trafic ! Regards, Olivier =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Lot's of debug information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D #vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 103, 16, 103, 0, 0 UMA Zones: 896, 0, 103, 1, 103, 0, 0 UMA Slabs: 568, 0, 1469, 8, 9360021, 0, 0 UMA RCntSlabs: 568, 0, 4001, 3, 4001, 0, 0 UMA Hash: 256, 0, 2, 13, 4, 0, 0 16 Bucket: 152, 0, 150, 0, 150, 0, 0 32 Bucket: 280, 0, 180, 2, 180, 0, 0 64 Bucket: 536, 0, 172, 3, 172, 57, 0 128 Bucket: 1048, 0, 3230, 1, 3230, 976, 0 VM OBJECT: 216, 0, 4065, 831,2135773858, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 530813, 61, 714,23586523, 0, 0 MAP ENTRY: 120, 0, 810, 1577,5002586805, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 243, 4, 243, 0, 0 16: 16, 0, 2831, 865,85083861, 0, 0 32: 32, 0, 3594, 850,6304456805, 0, 0 64: 64, 0, 7178, 718,7745903412, 0, 0 128: 128, 0, 7000, 830,867250399, 0, 0 256: 256, 0, 705, 375,2024001927, 0, 0 512: 512, 0, 1057, 987,510873956, 0, 0 1024: 1024, 0, 58, 258,513023562, 0, 0 2048: 2048, 0, 120, 254,2317784134, 0, 0 4096: 4096, 0, 390, 356,2024138031, 0, 0 Files: 80, 0, 148, 437,8727812960, 0, 0 TURNSTILE: 136, 0, 343, 77, 343, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 56, 187,73411021, 0, 0 THREAD: 1112, 0, 307, 35, 307, 0, 0 SLEEPQUEUE: 80, 0, 343, 92, 343, 0, 0 VMSPACE: 392, 0, 35, 195,73411191, 0, 0 cpuset: 72, 0, 2, 98, 2, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 6132, 1036,475290115, 0, 0 mbuf: 256, 0, 2189574, 383,576516959, 0, 0 mbuf_cluster: 2048, 25600, 7168, 726, 4067110, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 54, 92, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 224,11520248, 0, 0 ttyinq: 160, 0, 195, 213, 1530, 0, 0 ttyoutq: 256, 0, 103, 137, 805, 0, 0 ata_request: 328, 0, 0, 36, 15, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 VNODE: 480, 0, 18295, 577, 222953, 0, 0 VNODEPOLL: 112, 0, 0, 66, 1, 0, 0 NAMEI: 1024, 0, 0, 112,7075234360, 0, 0 S VFS Cache: 108, 0, 23897, 457, 612478, 0, 0 L VFS Cache: 328, 0, 94, 38, 95, 0, 0 DIRHASH: 1024, 0, 204, 36, 210, 0, 0 Mountpoints: 768, 0, 6, 19, 7, 0, 0 pipe: 728, 0, 8, 117,59501415, 0, 0 ksiginfo: 112, 0, 233, 823, 299396, 0, 0 itimer: 344, 0, 1, 32, 2, 0, 0 KNOTE: 128, 0, 4, 257,11228028, 0, 0 pfsrctrpl: 152, 10000, 0, 0, 0, 0, 0 pfrulepl: 936, 0, 1038, 1862,1925383509, 0, 0 pfstatepl: 288, 1200004, 14, 128075,14753578, 0, 0 pfstatekeypl: 288, 0, 14, 124695,14753578, 0, 0 pfstateitempl: 288, 0, 14, 124695,13482898, 0, 0 pfaltqpl: 240, 0, 4, 220, 7484484, 0, 0 pfpooladdrpl: 88, 0, 96, 492,179627616, 0, 0 pfrktable: 1296, 1002, 94, 314,215178991, 0, 0 pfrkentry: 160, 200016, 646, 1250,1218099746, 0, 0 pffrent: 32, 10100, 0, 707,270577665, 0, 0 pffrag: 80, 0, 0, 315, 6012837, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0, 0 pfstatescrub: 40, 0, 1, 839, 278667, 0, 0 pfiaddrpl: 120, 0, 0, 0, 0, 0, 0 pfospfen: 112, 0, 700, 356,1309784700, 0, 0 pfosfp: 40, 0, 410, 682,767159610, 0, 0 pfsync: 88, 0, 0, 210, 2228248, 0, 0 socket: 680, 25602, 78, 138,5471588693, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 62, 168,5038866279, 0, 0 udpcb: 16, 25704, 62, 946,5038866279, 0, 0 tcp_inpcb: 392, 25600, 2, 68, 18739, 0, 0 tcpcb: 976, 25600, 2, 34, 18739, 0, 0 tcptw: 72, 5150, 0, 0, 0, 0, 0 syncache: 152, 15375, 0, 75, 11, 0, 0 hostcache: 136, 15372, 0, 140, 9, 0, 0 tcpreass: 40, 1680, 0, 252, 53, 0, 0 sackhole: 32, 0, 0, 202, 5, 0, 0 sctp_ep: 1360, 25602, 0, 0, 0, 0, 0 sctp_asoc: 2272, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 360, 55, 0, 0 sctp_raddr: 688, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 0, 50, 18778, 0, 0 unpcb: 240, 25600, 12, 212,432684757, 0, 0 rtentry: 200, 0, 251, 91, 260, 0, 0 selfd: 56, 0, 467, 541,359441409, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 18238, 682, 222874, 0, 0 FFS1 dinode: 128, 0, 16697, 94, 16989, 0, 0 FFS2 dinode: 256, 0, 1541, 649, 205885, 0, 0 md0: 512, 0, 3458, 126, 3458, 0, 0 md1: 512, 0, 6178, 129, 6247, 0, 0 #netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 256 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 1 279350387 0 0 99299 27944968= 6 0 0 igmp 0 0 3 0 0 0 3 0 0 rtsock 0 3 0 0 0 259 259 0 0 arp 0 0 1553043 0 0 0 1553043 0 0 ether 0 0 808123139 0 0 0 80812313= 9 #dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE-p3 #0: Thu Jul 12 15:24:57 CEST 2012 root@FWALL-GEN:/usr/obj/FWALL.amd64/usr/local/Fall/FreeBSD/src/sys/FWAL= L-AMD64 amd64 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.11-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 6 Model =3D 1a St= epping =3D 5 Features=3D0xbfebfbff Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16480792576 (15717 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20110527/tbfadt-638) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 3 range: 1 vs 8100000000 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci11: on pcib1 bce0: mem 0x92000000-0x93ffffff irq 28 at device 0.0 on pci11 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: 00:21:5e:dd:06:e0 bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (5.0.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.3) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1: mem 0x94000000-0x95ffffff irq 40 at device 0.1 on pci11 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: 00:21:5e:dd:06:e2 bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (5.0.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.3) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib2: irq 29 at device 2.0 on pci0 pci16: on pcib2 pcib3: irq 24 at device 3.0 on pci0 pci21: on pcib3 pcib4: irq 30 at device 7.0 on pci0 pci26: on pcib4 pcib5: at device 0.0 on pci26 pci27: on pcib5 pcib6: at device 2.0 on pci27 pci28: on pcib6 em0: port 0x3020-0x303f mem 0x97b60000-0x97b7ffff,0x97b40000-0x97b5ffff irq 38 at device 0.0 on pci28 em0: Using an MSI interrupt em0: Ethernet address: 00:15:17:c4:48:15 em1: port 0x3000-0x301f mem 0x97b20000-0x97b3ffff,0x97b00000-0x97b1ffff irq 39 at device 0.1 on pci28 em1: Using an MSI interrupt em1: Ethernet address: 00:15:17:c4:48:14 pcib7: at device 4.0 on pci27 pci29: on pcib7 em2: port 0x2020-0x203f mem 0x97a60000-0x97a7ffff,0x97a40000-0x97a5ffff irq 37 at device 0.0 on pci29 em2: Using an MSI interrupt em2: Ethernet address: 00:15:17:c4:48:17 em3: port 0x2000-0x201f mem 0x97a20000-0x97a3ffff,0x97a00000-0x97a1ffff irq 30 at device 0.1 on pci29 em3: Using an MSI interrupt em3: Ethernet address: 00:15:17:c4:48:16 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0x40a0-0x40bf irq 17 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0x4080-0x409f irq 18 at device 26.1 on pci0 usbus1: on uhci1 ehci0: mem 0x97c21400-0x97c217ff irq 19 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 pcib8: irq 16 at device 28.0 on pci0 pci1: on pcib8 mpt0: port 0x1000-0x10ff mem 0x97910000-0x97913fff,0x97900000-0x9790ffff irq 16 at device 0.0 on pci1 mpt0: MPI Version=3D1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) pcib9: irq 16 at device 28.4 on pci0 pci6: on pcib9 pcib10: irq 16 at device 0.0 on pci6 pci7: on pcib10 vgapci0: mem 0x96000000-0x96ffffff,0x97800000-0x97803fff,0x97000000-0x977fffff irq 16 at device 0.0 on pci7 uhci2: port 0x4060-0x407f irq 17 at device 29.0 on pci0 usbus3: on uhci2 uhci3: port 0x4040-0x405f irq 18 at device 29.1 on pci0 usbus4: on uhci3 uhci4: port 0x4020-0x403f irq 19 at device 29.2 on pci0 usbus5: on uhci4 ehci1: mem 0x97c21000-0x97c213ff irq 17 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6: on ehci1 pcib11: at device 30.0 on pci0 pci31: on pcib11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40f0-0x40ff,0x40e0-0x40ef irq 16 at device 31.2 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) atapci1: port 0x4108-0x410f,0x4124-0x4127,0x4100-0x4107,0x4120-0x4123,0x40d0-0x40df,0x40c= 0-0x40cf irq 21 at device 31.5 on pci0 ata2: on atapci1 ata3: on atapci1 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard pcib12: pcibus 255 on qpi0 pci255: on pcib12 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state =3D 0x0003600E) bce1: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state =3D 0x0003600E) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered mpt0: mpt_read_cfg_page: Config Info Status 22 mpt0:vol0(mpt0:0:0): mpt_refresh_raid_vol: Failed to read RAID Vol Page(0) mpt0:vol0(mpt0:0:0): Settings ( ) mpt0:vol0(mpt0:0:0): 0 Members: mpt0:vol0(mpt0:0:0): RAID-0 - Optimal (mpt0:0:5): Physical (mpt0:0:5:0), Pass-thru (mpt0:1:0:0) (mpt0:0:5): Online (mpt0:0:4): Physical (mpt0:0:4:0), Pass-thru (mpt0:1:1:0) (mpt0:0:4): Online da0 at mpt0 bus 0 scbus0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 68664MB (140623872 512 byte sectors: 255H 63S/T 8753C) SMP: AP CPU #2 Launched! cd0 at ata0 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device SMP: AP CPU #1 Launched! cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #3 Launched! Root mount waiting for: usbus6 usbus2 uhub2: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ufs/FWALLs1a [ro]... ugen3.2: at usbus3 ugen5.2: at usbus5 ukbd0: on usbus5 kbd2 at ukbd0 ums0: on usbus5 ums0: 5 buttons and [XYZ] coordinates ID=3D1 altq: emulate 256000000Hz cpu clock bce0: link state changed to UP bce0: Gigabit link up! bce0: Gigabit link up! bce0: Gigabit link up! #pciconf -lvbc hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x72701014 chip=3D0x34068086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520 I/O Hub to ESI Port' class =3D bridge subclass =3D HOST-PCI cap 05[60] =3D MSI supports 2 messages, vector masks cap 10[90] =3D PCI-Express 2 root port max data 128(128) link x4(x4) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] =3D unknown 1 ecap 000b[160] =3D unknown 0 pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x34081014 chip=3D0x34088086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x34081014 cap 05[60] =3D MSI supports 2 messages, vector masks cap 10[90] =3D PCI-Express 2 root port max data 256(256) link x2(x2) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] =3D unknown 1 ecap 000b[160] =3D unknown 0 pcib2@pci0:0:2:0: class=3D0x060400 card=3D0x34091014 chip=3D0x34098086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 2' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x34091014 cap 05[60] =3D MSI supports 2 messages, vector masks cap 10[90] =3D PCI-Express 2 root port max data 256(256) link x0(x2) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] =3D unknown 1 pcib3@pci0:0:3:0: class=3D0x060400 card=3D0x340a1014 chip=3D0x340a8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 3' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x340a1014 cap 05[60] =3D MSI supports 2 messages, vector masks cap 10[90] =3D PCI-Express 2 root port max data 256(256) link x0(x16) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] =3D unknown 1 ecap 000b[160] =3D unknown 0 pcib4@pci0:0:7:0: class=3D0x060400 card=3D0x340e1014 chip=3D0x340e8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 7' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x340e1014 cap 05[60] =3D MSI supports 2 messages, vector masks cap 10[90] =3D PCI-Express 2 root port max data 256(256) link x4(x16) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] =3D unknown 1 ecap 000b[160] =3D unknown 0 none0@pci0:0:16:0: class=3D0x080000 card=3D0x00000000 chip=3D0x34258086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Physical and Link Layer Registers Port 0' class =3D base peripheral subclass =3D interrupt controller cap 09[50] =3D vendor (length 255) Intel cap 15 version 0 none1@pci0:0:16:1: class=3D0x080000 card=3D0x00000000 chip=3D0x34268086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Routing and Protocol Layer Registers Port= 0' class =3D base peripheral subclass =3D interrupt controller none2@pci0:0:17:0: class=3D0x080000 card=3D0x00000000 chip=3D0x34278086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500 Physical and Link Layer Registers Port 1' class =3D base peripheral subclass =3D interrupt controller cap 09[50] =3D vendor (length 255) Intel cap 15 version 0 none3@pci0:0:17:1: class=3D0x080000 card=3D0x00000000 chip=3D0x34288086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500 Routing & Protocol Layer Register Port 1' class =3D base peripheral subclass =3D interrupt controller none4@pci0:0:20:0: class=3D0x080000 card=3D0x00000000 chip=3D0x342e8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub System Management Registers' class =3D base peripheral subclass =3D interrupt controller cap 10[40] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) none5@pci0:0:20:1: class=3D0x080000 card=3D0x00000000 chip=3D0x34228086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers' class =3D base peripheral subclass =3D interrupt controller cap 10[40] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) none6@pci0:0:20:2: class=3D0x080000 card=3D0x00000000 chip=3D0x34238086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Control Status and RAS Registers' class =3D base peripheral subclass =3D interrupt controller cap 10[40] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) none7@pci0:0:20:3: class=3D0x080000 card=3D0x00000000 chip=3D0x34388086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Throttle Registers' class =3D base peripheral subclass =3D interrupt controller ioapic0@pci0:0:21:0: class=3D0x080020 card=3D0x00000000 chip=3D0x342f808= 6 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Trusted Execution Technology Registers' class =3D base peripheral subclass =3D interrupt controller none8@pci0:0:22:0: class=3D0x088000 card=3D0x34301014 chip=3D0x34308086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c00000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none9@pci0:0:22:1: class=3D0x088000 card=3D0x34311014 chip=3D0x34318086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c04000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none10@pci0:0:22:2: class=3D0x088000 card=3D0x34321014 chip=3D0x34328086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c08000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none11@pci0:0:22:3: class=3D0x088000 card=3D0x34331014 chip=3D0x34338086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c0c000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none12@pci0:0:22:4: class=3D0x088000 card=3D0x34291014 chip=3D0x34298086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c10000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none13@pci0:0:22:5: class=3D0x088000 card=3D0x342a1014 chip=3D0x342a8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c14000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none14@pci0:0:22:6: class=3D0x088000 card=3D0x342b1014 chip=3D0x342b8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c18000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 none15@pci0:0:22:7: class=3D0x088000 card=3D0x342c1014 chip=3D0x342c8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 Chipset QuickData Technology Device' class =3D base peripheral bar [10] =3D type Memory, range 64, base 0x97c1c000, size 16384, enab= led cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0= ) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0x3a371014 chip=3D0x3a378086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x40a0, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0x3a381014 chip=3D0x3a388086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x4080, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0x3a3c1014 chip=3D0x3a3c8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0x97c21400, size 1024, enabl= ed cap 01[50] =3D powerspec 2 supports D0 D3 current D0 cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] =3D PCI Advanced Features: FLR TP pcib8@pci0:0:28:0: class=3D0x060400 card=3D0x3a401014 chip=3D0x3a408086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x4(x4) cap 05[80] =3D MSI supports 1 message cap 0d[90] =3D PCI Bridge card=3D0x3a401014 cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 ecap 0002[100] =3D VC 1 max VC0 ecap 0005[180] =3D unknown 1 pcib9@pci0:0:28:4: class=3D0x060400 card=3D0x3a481014 chip=3D0x3a488086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Root Port 5' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] =3D MSI supports 1 message cap 0d[90] =3D PCI Bridge card=3D0x3a481014 cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 ecap 0002[100] =3D VC 1 max VC0 ecap 0005[180] =3D unknown 1 uhci2@pci0:0:29:0: class=3D0x0c0300 card=3D0x3a341014 chip=3D0x3a348086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x4060, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci3@pci0:0:29:1: class=3D0x0c0300 card=3D0x3a351014 chip=3D0x3a358086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x4040, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci4@pci0:0:29:2: class=3D0x0c0300 card=3D0x3a361014 chip=3D0x3a368086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x4020, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0x3a3a1014 chip=3D0x3a3a8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0x97c21000, size 1024, enabl= ed cap 01[50] =3D powerspec 2 supports D0 D3 current D0 cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] =3D PCI Advanced Features: FLR TP pcib11@pci0:0:30:0: class=3D0x060401 card=3D0x244e1014 chip=3D0x244e8086 rev=3D0x90 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 PCI Bridge' class =3D bridge subclass =3D PCI-PCI cap 0d[50] =3D PCI Bridge card=3D0x244e1014 isab0@pci0:0:31:0: class=3D0x060100 card=3D0x3a181014 chip=3D0x3a188086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JIB (ICH10) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 features: Quick Resume, SATA RAID-5, 4 PCI-e x1 slots, SATA RAID-0= /1/10 atapci0@pci0:0:31:2: class=3D0x01018a card=3D0x3a201014 chip=3D0x3a20808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) 4 port SATA IDE Controller' class =3D mass storage subclass =3D ATA bar [20] =3D type I/O Port, range 32, base 0x40f0, size 16, enabled bar [24] =3D type I/O Port, range 32, base 0x40e0, size 16, enabled cap 01[70] =3D powerspec 3 supports D0 D3 current D0 cap 13[b0] =3D PCI Advanced Features: FLR TP none16@pci0:0:31:3: class=3D0x0c0500 card=3D0x3a301014 chip=3D0x3a308086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) SMBus Controller' class =3D serial bus subclass =3D SMBus bar [10] =3D type Memory, range 64, base 0x97c21800, size 256, enable= d bar [20] =3D type I/O Port, range 32, base 0x4000, size 32, enabled atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x3a261014 chip=3D0x3a26808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) 2 port SATA IDE Controller' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0x4108, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0x4124, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0x4100, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x4120, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0x40d0, size 16, enabled bar [24] =3D type I/O Port, range 32, base 0x40c0, size 16, enabled cap 01[70] =3D powerspec 3 supports D0 D3 current D0 cap 13[b0] =3D PCI Advanced Features: FLR TP bce0@pci0:11:0:0: class=3D0x020000 card=3D0x03a91014 chip=3D0x163914e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II BCM5709 Gigabit Ethernet' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0x92000000, size 33554432, e= nabled cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 03[50] =3D VPD cap 05[58] =3D MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] =3D MSI-X supports 9 messages in map 0x10 cap 10[ac] =3D PCI-Express 2 endpoint max data 256(512) link x2(x4) ecap 0003[100] =3D Serial 1 00215efffedd06e0 ecap 0001[110] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] =3D unknown 1 ecap 0002[160] =3D VC 1 max VC0 bce1@pci0:11:0:1: class=3D0x020000 card=3D0x03a91014 chip=3D0x163914e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II BCM5709 Gigabit Ethernet' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0x94000000, size 33554432, e= nabled cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 03[50] =3D VPD cap 05[58] =3D MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] =3D MSI-X supports 9 messages in map 0x10 cap 10[ac] =3D PCI-Express 2 endpoint max data 256(512) link x2(x4) ecap 0003[100] =3D Serial 1 00215efffedd06e2 ecap 0001[110] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] =3D unknown 1 ecap 0002[160] =3D VC 1 max VC0 pcib5@pci0:26:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x8018111d rev=3D0x0e hdr=3D0x01 vendor =3D 'Integrated Device Technology, Inc.' device =3D 'PES12N3A PCI Express Switch' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 upstream port max data 256(2048) link x4(x= 4) cap 01[c0] =3D powerspec 3 supports D0 D3 current D0 ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[200] =3D VC 1 max VC0 pcib6@pci0:27:2:0: class=3D0x060400 card=3D0x00000000 chip=3D0x8018111d rev=3D0x0e hdr=3D0x01 vendor =3D 'Integrated Device Technology, Inc.' device =3D 'PES12N3A PCI Express Switch' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 downstream port max data 256(2048) link x4= (x4) cap 01[c0] =3D powerspec 3 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[200] =3D VC 1 max VC0 pcib7@pci0:27:4:0: class=3D0x060400 card=3D0x00000000 chip=3D0x8018111d rev=3D0x0e hdr=3D0x01 vendor =3D 'Integrated Device Technology, Inc.' device =3D 'PES12N3A PCI Express Switch' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 downstream port max data 256(2048) link x4= (x4) cap 01[c0] =3D powerspec 3 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[200] =3D VC 1 max VC0 em0@pci0:28:0:0: class=3D0x020000 card=3D0x11bc8086 chip=3D0x10bc8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82571EB Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0x97b60000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0x97b40000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x3020, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 001517ffffc44814 em1@pci0:28:0:1: class=3D0x020000 card=3D0x11bc8086 chip=3D0x10bc8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82571EB Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0x97b20000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0x97b00000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x3000, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 001517ffffc44814 em2@pci0:29:0:0: class=3D0x020000 card=3D0x11bc8086 chip=3D0x10bc8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82571EB Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0x97a60000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0x97a40000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x2020, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 001517ffffc44816 em3@pci0:29:0:1: class=3D0x020000 card=3D0x11bc8086 chip=3D0x10bc8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82571EB Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0x97a20000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0x97a00000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x2000, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 001517ffffc44816 mpt0@pci0:1:0:0: class=3D0x010000 card=3D0x03941014 chip=3D0x00581000 rev=3D0x08 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'SAS1068E PCI-Express Fusion-MPT SAS' class =3D mass storage subclass =3D SCSI bar [10] =3D type I/O Port, range 32, base 0x1000, size 256, disabled bar [14] =3D type Memory, range 64, base 0x97910000, size 16384, enab= led bar [1c] =3D type Memory, range 64, base 0x97900000, size 65536, enab= led cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 cap 10[68] =3D PCI-Express 1 endpoint max data 128(4096) link x4(x8) cap 05[98] =3D MSI supports 1 message, 64 bit cap 11[b0] =3D MSI-X supports 1 message in map 0x14 enabled ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected pcib10@pci0:6:0:0: class=3D0x060400 card=3D0x03691014 chip=3D0x0452101b rev=3D0x01 hdr=3D0x01 vendor =3D 'Vitesse Semiconductor' device =3D 'VSC452 [SuperBMC]' class =3D bridge subclass =3D PCI-PCI cap 05[50] =3D MSI supports 2 messages, 64 bit cap 01[78] =3D powerspec 3 supports D0 D3 current D0 cap 10[80] =3D PCI-Express 1 PCI bridge max data 128(128) link x1(x1) cap 0d[a4] =3D PCI Bridge card=3D0x03691014 ecap 0002[100] =3D VC 1 max VC0 vgapci0@pci0:7:0:0: class=3D0x030000 card=3D0x03691014 chip=3D0x0530102b rev=3D0x00 hdr=3D0x00 vendor =3D 'Matrox Graphics, Inc.' device =3D 'MGA G200EV' class =3D display subclass =3D VGA bar [10] =3D type Prefetchable Memory, range 32, base 0x96000000, size 16777216, enabled bar [14] =3D type Memory, range 32, base 0x97800000, size 16384, enab= led bar [18] =3D type Memory, range 32, base 0x97000000, size 8388608, en= abled cap 01[dc] =3D powerspec 1 supports D0 D3 current D0 hostb1@pci0:255:0:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c40808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture Generic Non-Core Registers' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:255:0:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c01808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture System Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:255:2:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c10808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Link 0' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:255:2:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c11808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Physical 0' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:255:2:4: class=3D0x060000 card=3D0x80868086 chip=3D0x2c14808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Link 1' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:255:2:5: class=3D0x060000 card=3D0x80868086 chip=3D0x2c15808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Physical 1' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:255:3:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c18808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:255:3:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c19808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Target Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:255:3:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2c1a808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller RAS Regi= sters' class =3D bridge subclass =3D HOST-PCI hostb10@pci0:255:3:4: class=3D0x060000 card=3D0x80868086 chip=3D0x2c1c8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Test Reg= isters' class =3D bridge subclass =3D HOST-PCI hostb11@pci0:255:4:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c208086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb12@pci0:255:4:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c218086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb13@pci0:255:4:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2c228086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb14@pci0:255:4:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2c238086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb15@pci0:255:5:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c288086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb16@pci0:255:5:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c298086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb17@pci0:255:5:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2c2a8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb18@pci0:255:5:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2c2b8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb19@pci0:255:6:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c308086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb20@pci0:255:6:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2c318086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb21@pci0:255:6:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2c328086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb22@pci0:255:6:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2c338086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 14:14:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45DBCA9A; Fri, 12 Apr 2013 14:14:42 +0000 (UTC) (envelope-from jmojica@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 991859F6; Fri, 12 Apr 2013 14:14:41 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id c11so2804787wgh.32 for ; Fri, 12 Apr 2013 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Og77f+5WQ62Rwg/4Vu4iuAE3AhyQDzIz8e+K6bSrLP0=; b=ACf3FD0qcXJKBenBPDO6ZYArK75SMsRNhQ4MTbcS+tcam0g/rfj6BBvD2l1T58u+Lb ubgNjCnYZr4jEMdtq9laoJpQoilIlU1bxY0NgorAWLIV8K+rGK7YQRcJ4Ibo7BNDVMtj KyDIxcTQvO4Hz/Mg04CixKdZwjAYdbFi+wZmeaeVPPFWxi2mCfqPi5fwRywI4azDMcjH DlJcQ9m425s/Sqp1rReoHFGbvF8Ti3dzPgw91MspoMk3MNPZ9xhSXO8vDuu+sYRCDchi ufudNoDEd0QfQvk4cjnt48ZrPf/shFYUwO7G5JLQ+UpfvzqkP4PXA1wKbaXeQjqO5sbG YPUg== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr4367349wib.23.1365776080317; Fri, 12 Apr 2013 07:14:40 -0700 (PDT) Received: by 10.194.122.73 with HTTP; Fri, 12 Apr 2013 07:14:40 -0700 (PDT) In-Reply-To: <20130409184439.GA62925@x2.osted.lan> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> <20130409081652.GA50498@x2.osted.lan> <5163D2D2.2090407@freebsd.org> <20130409184439.GA62925@x2.osted.lan> Date: Fri, 12 Apr 2013 10:14:40 -0400 Message-ID: Subject: Re: panic in tcp_do_segment() From: Juan Mojica To: Peter Holm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Rick Macklem , Andre Oppermann , Matt Miller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:14:42 -0000 I'm a little late to get back to the email thread, but this is great to hear. Changes look good (assuming the goto drop is changed dropunlock). Thanks guys. On Tue, Apr 9, 2013 at 2:44 PM, Peter Holm wrote: > On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote: > > On 09.04.2013 10:16, Peter Holm wrote: > > > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote: > > >> On 05.04.2013 13:09, Matt Miller wrote: > > >>> Hey Rick, > > >>> > > >>> I believe Juan and I have root caused this crash recently. The > t_state = > > >>> 0x1, TCPS_LISTEN, in the link provided at the time of the assertion. > > >>> > > >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set > on the > > >>> socket and we should never enter tcp_do_segment() for this state. I > think > > >>> if you look in your corefile, you'll see the socket *doesn't* have > this > > >>> flag set in your case. > > >>> > > >>> 1043 /* > > >>> 1044 * When the socket is accepting connections (the INPCB > is in > > >>> LISTEN > > >>> 1045 * state) we look into the SYN cache if this is a new > > >>> connection > > >>> 1046 * attempt or the completion of a previous one. > Because listen > > >>> 1047 * sockets are never in TCPS_ESTABLISHED, the V_tcbinfo > lock > > >>> will be > > >>> 1048 * held in this case. > > >>> 1049 */ > > >>> 1050 if (so->so_options & SO_ACCEPTCONN) { > > >>> 1051 struct in_conninfo inc; > > >>> 1052 > > >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so > accepting > > >>> but " > > >>> 1054 "tp not listening", __func__)); > > >>> ... > > >>> 1356 syncache_add(&inc, &to, th, inp, &so, m, NULL, > NULL); > > >>> 1357 /* > > >>> 1358 * Entry added to syncache and mbuf consumed. > > >>> 1359 * Everything already unlocked by > syncache_add(). > > >>> 1360 */ > > >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > > >>> 1362 return; > > >>> 1363 } > > >>> ... > > >>> 1384 /* > > >>> 1385 * Segment belongs to a connection in SYN_SENT, > ESTABLISHED or > > >>> later > > >>> 1386 * state. tcp_do_segment() always consumes the mbuf > chain, > > >>> unlocks > > >>> 1387 * the inpcb, and unlocks pcbinfo. > > >>> 1388 */ > > >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, iptos, > > >>> ti_locked); > > >>> > > >>> I think this has to do with this patch in soclose() where > SO_ACCEPTCONN is > > >>> being turned off in soclose(). I suspect if you look at the other > threads > > >>> in your corefile, you'll see one at this point in soclose() > operating on > > >>> the same socket as the one in the tcp_do_segment() thread. > > >>> > > >>> http://svnweb.freebsd.org/base?view=revision&revision=243627 > > >>> > > >>> 817 /* > > >>> 818 * Prevent new additions to the accept queues > due > > >>> 819 * to ACCEPT_LOCK races while we are draining > them. > > >>> 820 */ > > >>> 821 so->so_options &= ~SO_ACCEPTCONN; > > >>> 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) != > NULL) { > > >>> 823 TAILQ_REMOVE(&so->so_incomp, sp, > so_list); > > >>> 824 so->so_incqlen--; > > >>> 825 sp->so_qstate &= ~SQ_INCOMP; > > >>> 826 sp->so_head = NULL; > > >>> 827 ACCEPT_UNLOCK(); > > >>> 828 soabort(sp); > > >>> 829 ACCEPT_LOCK(); > > >>> 830 } > > >>> > > >>> Juan had evaluated this code path and it seemed safe to just drop the > > >>> packet in this case: > > >>> > > >>> + /* > > >>> + * In closing down the socket, the SO_ACCEPTCONN flag is > removed to > > >>> + * prevent new connections from being established. This means > that > > >>> + * any frames in that were in the midst of being processed > could > > >>> + * make it here. Need to just drop the frame. > > >>> + */ > > >>> + if (TCPS_LISTEN == tp->t_state) { > > >>> + TCPSTAT_INC(tcps_rcvwhileclosing); > > >>> + goto drop; > > >>> + } > > >>> KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > > >>> __func__)); > > >>> > > >>> Or, if there's someone more familiar with the locking in these > paths, they > > >>> may be able to come up with a way to restructure the locks and logic > to > > >>> close this window. > > >> > > >> Matt, Juan, > > >> > > >> excellent analysis. I don't see a better approach to handle this > > >> under the current ACCEPT_LOCK model. > > >> > > >> Compared to your patch I'd like to handle this race earlier before > > >> we hit tcp_do_segment(). > > >> > > >> Could you please review the attached patch which handles it right > > >> after the SO_ACCEPTCONN / syncache check? > > >> > > >> -- > > >> Andre > > >> > > >> Index: netinet/tcp_input.c > > >> =================================================================== > > >> --- netinet/tcp_input.c (revision 249253) > > >> +++ netinet/tcp_input.c (working copy) > > >> @@ -1351,6 +1351,16 @@ > > >> */ > > >> INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > > >> return; > > >> + } else if (tp->t_state == TCPS_LISTEN) { > > >> + /* > > >> + * When a listen socket is torn down the SO_ACCEPTCONN > > >> + * flag is removed first while connections are drained > > >> + * from the accept queue in a unlock/lock cycle of the > > >> + * ACCEPT_LOCK, opening a race condition allowing a SYN > > >> + * attempt go through unhandled. > > >> + */ > > >> + TCPSTAT_INC(tcps_rcvdwhileclosing); > > >> + goto drop; > > >> } > > >> > > >> #ifdef TCP_SIGNATURE > > > > > > I was able to reproduce the original "panic: tcp_do_segment: > > > TCPS_LISTEN" with ease; see > > > http://people.freebsd.org/~pho/stress/log/tcp.txt. > > > > > > With your patch (minus the TCPSTAT_INC) I got this "panic: Lock (rw) > > > tcp locked @ netinet/tcp_input.c:1432." > > > > > > http://people.freebsd.org/~pho/stress/log/tcp2.txt > > > > Please replace the 'goto drop' with 'goto dropunlock' to fix the panic. > > > > Yes, this seems to take care of the two problems reported. Tested for > 5 hours without any repeats. > > - Peter > -- Juan Mojica Email: jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 14:48:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E1EF8D1 for ; Fri, 12 Apr 2013 14:48:19 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id F11FDB4F for ; Fri, 12 Apr 2013 14:48:18 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wp18so2419826obc.28 for ; Fri, 12 Apr 2013 07:48:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=htz/AbolhMtJK2Xf/JmcfEBY1G/3cB0brzSTwpBfyDM=; b=ZB84SRio6263ae7tW7MAfIh9SxWRc1aawJrFPK1VwnwCOTRgK0vAaVs5FKOOAA6ipf JqgCciFTSlNknWtQAtlqFDQoPFt5csdTYs8Y4mlSLf+qgbYYwz2tmbqK42yBMP3xlSVh EkQ/Gfdp13L679O5KyGOOW7LJyKX5fuHuoBtxVHOo2yGgeg+i9mHbzC+u/Tekx4ZJETf KOKBhk+Nx/87bYV9SgGI68VjnrQihyhO/rKciT7HV7EK4biceI86Fe7Y7+e7WAYbc5yo kDiaRRtTbN8DOYb5NbeiBVKIcsKEse0YOOk5g026Xy0pr3ndkzmFR/uaVnjOCBeNRYrz 23sg== MIME-Version: 1.0 X-Received: by 10.182.127.115 with SMTP id nf19mr3992062obb.49.1365778097551; Fri, 12 Apr 2013 07:48:17 -0700 (PDT) Received: by 10.60.140.229 with HTTP; Fri, 12 Apr 2013 07:48:17 -0700 (PDT) In-Reply-To: <51679B54.2060908@rdtc.ru> References: <516739C9.4080902@denninger.net> <51679B54.2060908@rdtc.ru> Date: Fri, 12 Apr 2013 07:48:17 -0700 Message-ID: Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? From: Michael Sierchio To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkc8L8PL6CgB+5mDNDimuMDqUZWeuD6oqjpSK8zAkn/ylL76aE0Olw7x71cqAmxjeovzL7z Cc: freebsd-net , Karl Denninger X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:48:19 -0000 On Thu, Apr 11, 2013 at 10:27 PM, Eugene Grosbein wrote= : > 12.04.2013 05:31, Karl Denninger =D0=C9=DB=C5=D4: >> Is there a "cookbook" for setting this up? There are examples for >> setting up a tunnel between two fixed-address networks (e.g. a remote >> LAN that needs to be "integrated" with a central LAN over IPSec but I >> can't find anything addressing the other situation -- remote user(s) >> where the connecting IPs are not known in advance, such as a person with >> a laptop or smartphone in a random hotel. > You'll need to install the port security/ipsec-tools for IKE protocol sup= port. > This port contains racoon daemon, here is sample racoon.conf: You may need something not in the GENERIC kernel on the server side options IPSEC_NAT_T and if you're supporting OS X clients with L2TP, you'll want to install mpd5 from the ports. And patch racoon to use a single shared secret across users. Howto set up a L2TP/IPsec VPN Dial-In Server http://forums.freebsd.org/showthread.php?t=3D26755 - M From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 15:43:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A382679 for ; Fri, 12 Apr 2013 15:43:37 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id B6B56F05 for ; Fri, 12 Apr 2013 15:43:36 +0000 (UTC) Received: (qmail 43737 invoked from network); 12 Apr 2013 15:43:34 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 12 Apr 2013 15:43:34 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r3CFhWuA046447; Fri, 12 Apr 2013 17:43:32 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r3CFhVvB046446; Fri, 12 Apr 2013 17:43:31 +0200 (CEST) (envelope-from pho) Date: Fri, 12 Apr 2013 17:43:31 +0200 From: Peter Holm To: Juan Mojica Subject: Re: panic in tcp_do_segment() Message-ID: <20130412154331.GA46423@x2.osted.lan> References: <1043692819.529554.1365114790772.JavaMail.root@erie.cs.uoguelph.ca> <5162B474.6060808@freebsd.org> <20130409081652.GA50498@x2.osted.lan> <5163D2D2.2090407@freebsd.org> <20130409184439.GA62925@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net , Rick Macklem , Andre Oppermann , Matt Miller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:43:37 -0000 On Fri, Apr 12, 2013 at 10:14:40AM -0400, Juan Mojica wrote: Glad I could help. - Peter > I'm a little late to get back to the email thread, but this is great to > hear. Changes look good (assuming the goto drop is changed > dropunlock). Thanks guys. > > On Tue, Apr 9, 2013 at 2:44 PM, Peter Holm <[1]peter@holm.cc> wrote: > > On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote: > > On 09.04.2013 10:16, Peter Holm wrote: > > > On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote: > > >> On 05.04.2013 13:09, Matt Miller wrote: > > >>> Hey Rick, > > >>> > > >>> I believe Juan and I have root caused this crash recently. The > t_state = > > >>> 0x1, TCPS_LISTEN, in the link provided at the time of the > assertion. > > >>> > > >>> In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be > set on the > > >>> socket and we should never enter tcp_do_segment() for this state. > I think > > >>> if you look in your corefile, you'll see the socket *doesn't* > have this > > >>> flag set in your case. > > >>> > > >>> 1043 /* > > >>> 1044 * When the socket is accepting connections (the > INPCB is in > > >>> LISTEN > > >>> 1045 * state) we look into the SYN cache if this is a > new > > >>> connection > > >>> 1046 * attempt or the completion of a previous one. > Because listen > > >>> 1047 * sockets are never in TCPS_ESTABLISHED, the > V_tcbinfo lock > > >>> will be > > >>> 1048 * held in this case. > > >>> 1049 */ > > >>> 1050 if (so->so_options & SO_ACCEPTCONN) { > > >>> 1051 struct in_conninfo inc; > > >>> 1052 > > >>> 1053 KASSERT(tp->t_state == TCPS_LISTEN, ("%s: so > accepting > > >>> but " > > >>> 1054 "tp not listening", __func__)); > > >>> ... > > >>> 1356 syncache_add(&inc, &to, th, inp, &so, m, > NULL, NULL); > > >>> 1357 /* > > >>> 1358 * Entry added to syncache and mbuf > consumed. > > >>> 1359 * Everything already unlocked by > syncache_add(). > > >>> 1360 */ > > >>> 1361 INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > > >>> 1362 return; > > >>> 1363 } > > >>> ... > > >>> 1384 /* > > >>> 1385 * Segment belongs to a connection in SYN_SENT, > ESTABLISHED or > > >>> later > > >>> 1386 * state. tcp_do_segment() always consumes the mbuf > chain, > > >>> unlocks > > >>> 1387 * the inpcb, and unlocks pcbinfo. > > >>> 1388 */ > > >>> 1389 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen, > iptos, > > >>> ti_locked); > > >>> > > >>> I think this has to do with this patch in soclose() where > SO_ACCEPTCONN is > > >>> being turned off in soclose(). I suspect if you look at the > other threads > > >>> in your corefile, you'll see one at this point in soclose() > operating on > > >>> the same socket as the one in the tcp_do_segment() thread. > > >>> > > >>> [2]http://svnweb.freebsd.org/base?view=revision&revision=243627 > > >>> > > >>> 817 /* > > >>> 818 * Prevent new additions to the accept > queues due > > >>> 819 * to ACCEPT_LOCK races while we are > draining them. > > >>> 820 */ > > >>> 821 so->so_options &= ~SO_ACCEPTCONN; > > >>> 822 while ((sp = TAILQ_FIRST(&so->so_incomp)) > != NULL) { > > >>> 823 TAILQ_REMOVE(&so->so_incomp, sp, > so_list); > > >>> 824 so->so_incqlen--; > > >>> 825 sp->so_qstate &= ~SQ_INCOMP; > > >>> 826 sp->so_head = NULL; > > >>> 827 ACCEPT_UNLOCK(); > > >>> 828 soabort(sp); > > >>> 829 ACCEPT_LOCK(); > > >>> 830 } > > >>> > > >>> Juan had evaluated this code path and it seemed safe to just drop > the > > >>> packet in this case: > > >>> > > >>> + /* > > >>> + * In closing down the socket, the SO_ACCEPTCONN flag is > removed to > > >>> + * prevent new connections from being established. This > means that > > >>> + * any frames in that were in the midst of being processed > could > > >>> + * make it here. Need to just drop the frame. > > >>> + */ > > >>> + if (TCPS_LISTEN == tp->t_state) { > > >>> + TCPSTAT_INC(tcps_rcvwhileclosing); > > >>> + goto drop; > > >>> + } > > >>> KASSERT(tp->t_state > TCPS_LISTEN, ("%s: TCPS_LISTEN", > > >>> __func__)); > > >>> > > >>> Or, if there's someone more familiar with the locking in these > paths, they > > >>> may be able to come up with a way to restructure the locks and > logic to > > >>> close this window. > > >> > > >> Matt, Juan, > > >> > > >> excellent analysis. I don't see a better approach to handle this > > >> under the current ACCEPT_LOCK model. > > >> > > >> Compared to your patch I'd like to handle this race earlier before > > >> we hit tcp_do_segment(). > > >> > > >> Could you please review the attached patch which handles it right > > >> after the SO_ACCEPTCONN / syncache check? > > >> > > >> -- > > >> Andre > > >> > > >> Index: netinet/tcp_input.c > > >> > =================================================================== > > >> --- netinet/tcp_input.c (revision 249253) > > >> +++ netinet/tcp_input.c (working copy) > > >> @@ -1351,6 +1351,16 @@ > > >> */ > > >> INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); > > >> return; > > >> + } else if (tp->t_state == TCPS_LISTEN) { > > >> + /* > > >> + * When a listen socket is torn down the SO_ACCEPTCONN > > >> + * flag is removed first while connections are drained > > >> + * from the accept queue in a unlock/lock cycle of the > > >> + * ACCEPT_LOCK, opening a race condition allowing a SYN > > >> + * attempt go through unhandled. > > >> + */ > > >> + TCPSTAT_INC(tcps_rcvdwhileclosing); > > >> + goto drop; > > >> } > > >> > > >> #ifdef TCP_SIGNATURE > > > > > > I was able to reproduce the original "panic: tcp_do_segment: > > > TCPS_LISTEN" with ease; see > > > [3]http://people.freebsd.org/~pho/stress/log/tcp.txt. > > > > > > With your patch (minus the TCPSTAT_INC) I got this "panic: Lock > (rw) > > > tcp locked @ netinet/tcp_input.c:1432." > > > > > > [4]http://people.freebsd.org/~pho/stress/log/tcp2.txt > > > > Please replace the 'goto drop' with 'goto dropunlock' to fix the > panic. > > > > Yes, this seems to take care of the two problems reported. Tested > for > 5 hours without any repeats. > - Peter > > -- > Juan Mojica > Email: [5]jmojica@gmail.com > > References > > 1. mailto:peter@holm.cc > 2. http://svnweb.freebsd.org/base?view=revision&revision=243627 > 3. http://people.freebsd.org/~pho/stress/log/tcp.txt > 4. http://people.freebsd.org/~pho/stress/log/tcp2.txt > 5. mailto:jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 15:46:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EAE9079E; Fri, 12 Apr 2013 15:46:17 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by mx1.freebsd.org (Postfix) with ESMTP id C342BF41; Fri, 12 Apr 2013 15:46:17 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id bj3so1523297pad.6 for ; Fri, 12 Apr 2013 08:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:content-type:date:message-id :mime-version:x-mailer; bh=Vt1xJO5NIHghJzNkT8qFknEoUYYxVGO3Anj1sByxuGU=; b=zE4P0rixnVkxtlQhuaKSlZVI7sMEPt3W/iYtvUu2H8afKM5/PqSKWc/K97Akx7WLlH qYA5dWleIN0PKLap2W+yopYNqHRADR0L5nRamJtK+EJ3zXaBbBiratJs5C48Fw7HWDo+ XVe3TSnDxSgRqRk+bpLnt2qNkVDH209x1pc9sKIZPdDMdOur0p8TcjXPfAKC+edAcgzX Rk15ZfsAL7tW1Vjkih9Bna5V3cwU1CP+u0vzrsyALYyeeCNMQ9PN2kWx3u5iuHKtavsu MiBci47wfE+RufyaTxuxasnDO9LvEyX5ApOZsPUYgXqPjwBNdE7tWT1EwJkzPnRIL7ot mk7A== X-Received: by 10.68.189.67 with SMTP id gg3mr10367113pbc.141.1365781571594; Fri, 12 Apr 2013 08:46:11 -0700 (PDT) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com. [209.131.62.116]) by mx.google.com with ESMTPS id to7sm10078804pab.0.2013.04.12.08.46.09 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 08:46:10 -0700 (PDT) Subject: bge(4) sysctl tuneables -- a blast from the past. From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-oo8aAxUI/ZVh33QES1XL" Date: Fri, 12 Apr 2013 08:46:08 -0700 Message-ID: <1365781568.1418.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "pyunyh@gmail.com" , bde@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:46:18 -0000 --=-oo8aAxUI/ZVh33QES1XL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://markmail.org/message/brpfcifnf2742pff So, these never happened. *sigh* I think they should. Any objections? Sean --=-oo8aAxUI/ZVh33QES1XL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRaCw5AAoJEBkJRdwI6BaHChYH/RpF4Lod/HXXyoHGLN8G9rSG AM4t4u2LmbpAS14qhUQpFOQsOhJrRFVnsZ37wnZX9veXrYG2DFhoQcET9FOVNA7C uuO3M6ADNbauXqCHC/UKOLXJvW0aIFUTV4MpG8i51PBJsc2ULcmC52paigFP1WKn HilAaCWNRGy0heeTF5B4TKZtNBDZjAtN98qRdalolad9x9Ji0EhlzwbeLylO57Db rW1ABHEHF1D51kUjlV6naI8CuG/hMqnizzUE0vEb712QJeLfYHhvaCOiVUc4Ey8a L2AmhgsM3gnsD2GmjpQJC/YitVcKm5Leibbp9Hj6Iwkz2S6kl7E1lVd5qqnUoW0= =URWj -----END PGP SIGNATURE----- --=-oo8aAxUI/ZVh33QES1XL-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 20:56:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A10E8F8C; Fri, 12 Apr 2013 20:56:38 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7A64A1D19; Fri, 12 Apr 2013 20:56:38 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id 5so1609829pdd.3 for ; Fri, 12 Apr 2013 13:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:content-type:date:message-id :mime-version:x-mailer; bh=8tUjrDesj7gwr7rhfgOP221dRteACTjhlU/Togtd5As=; b=GuhJ6KCk78q8SafqwMGvQnQQh65pIUWXxiQBhtskXUcwWmMp5Ys82lxHfxkiIZhP1m ch5hsFrgR7wkQsG/Yh7YdS+ija5q/zVE0TsFFyoMbqCATo7ht8I7QvQjUGDoGHT4AZyj nh6x69stJgkIx2cd+V/aQfFPUKUZvWuwD1HN6F6z2Gm1Dku4FAo+JSIChptvvN42cfMr 2ScMgtrRyUro/meiN3pyId5FgTrmycjxHuIQYtKUsRUkn9ywEYMm8DrIzgGVuQCeGznW uP4MoKm9+uOKBbqcLT1xuQD6VIE8kDAzBNql4WG1RpzKqsLF4U1tsb++SC4ceXTsQHjx NJyQ== X-Received: by 10.66.84.74 with SMTP id w10mr17160760pay.214.1365800192242; Fri, 12 Apr 2013 13:56:32 -0700 (PDT) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com. [209.131.62.116]) by mx.google.com with ESMTPS id to7sm10963677pab.0.2013.04.12.13.56.29 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 13:56:30 -0700 (PDT) Subject: bce(4) on the Dell PE 2950 From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-N489thMbaCvejvCVVXTl" Date: Fri, 12 Apr 2013 13:56:28 -0700 Message-ID: <1365800188.1418.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 20:56:38 -0000 --=-N489thMbaCvejvCVVXTl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A note from clusteradm@freebsd.org=20 It looks like there is some amount of instability or bugginess in some of the Broadcom firmware(management) on the bce(4) chipeset shipped on later generations of the Poweredge 2950 from Dell: bce0: Specifically, we've seen that newer (9 and higher) have issues with the doing initial setup and negotiation and that Dell did indeed release newer firmware to fix the issues. This requires a full reboot into Linux (probably centos6) to get the update to execute. Sean --=-N489thMbaCvejvCVVXTl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRaHT8AAoJEBkJRdwI6BaHcIwH/1e3Y68zZ6IYdjuFy8Fo49Ps VjEm0RjAPfEuVn26F6V2nLl+YWUbKl58r4w0f43LQ2dslnPCiGVlUFaVGGfztDUy 1gyGOvA4ZrXe1mOz0v+wa93qdDZVTSFqQVu+mlDwbu1RR45K7h+Aw00wvNXsecKK V4WrMVnk7Mw3vgisBpc4+ziEKF0huLBZ6cTZfEP6g65XRL3gCrI1SboGH7V+uX9x T1ABa0Fjk/4VGTRdNsUC+DeM0o0I8Blir8VfNyBj/hA30eTfidbeeE/26CacXfBX ahQ4SiKyHPwgg9iZCJPvqVS+lWyzcxHqLcZaTtI0EDqvbc4kyYUu5BkH/1ZI/rM= =0FfW -----END PGP SIGNATURE----- --=-N489thMbaCvejvCVVXTl-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 21:09:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 48DA4177; Fri, 12 Apr 2013 21:09:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 32C901D82; Fri, 12 Apr 2013 21:09:00 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 10E11CFC3; Fri, 12 Apr 2013 14:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1365800940; bh=5ToSkSTd08OQp6LbDetn7+koKA9W800UyapURaXaoTM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=cbI1WpMoc69NKiLhvEdxWI+h58sQfoCDoOXqzDxD+IuKQbWhXORAx7pfQM0My/LQA hL0PlhE+oQY5GUe/5i7gwPFFmx4yVo0FwB6cy/ef3TMC/bupoPzjb/K/Ksz0By6Ue0 DI5EqZxomZWoAG1hMLhSmK3WcH069a6xSxE5bmBE= Message-ID: <516877F0.9080301@delphij.net> Date: Fri, 12 Apr 2013 14:09:04 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 References: <1365800188.1418.29.camel@localhost> In-Reply-To: <1365800188.1418.29.camel@localhost> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , davidch@FreeBSD.org, Sean Bruno X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:09:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (Added David to Cc) On 04/12/13 13:56, Sean Bruno wrote: > A note from clusteradm@freebsd.org > > It looks like there is some amount of instability or bugginess in > some of the Broadcom firmware(management) on the bce(4) chipeset > shipped on later generations of the Poweredge 2950 from Dell: > > bce0: > > Specifically, we've seen that newer (9 and higher) have issues with > the doing initial setup and negotiation and that Dell did indeed > release newer firmware to fix the issues. This requires a full > reboot into Linux (probably centos6) to get the update to execute. I could be wrong but I *think* that the firmware is loaded on device initialization, so there may be a chance that the driver can do it when starting? Additionally, maybe one can leverage the kernel firmware(9) framework so that the firmware can be more easily updated by user? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRaHfwAAoJEG80Jeu8UPuz5EkIAMpC9/vKi62HGPSZKWO5KqH3 FhcizlRvcTigseHQoYG3zkd1TpW7TJ0iium/MSadix4vhck5TWA6CoACAdFLH65a KbI3UHmbfi5PlBKBm+mGumuTTzBOpC+c+Lt0c6AGEpo1cDjD3UqvAz/p12NQ30S2 dv0tugJhGlmcrNbWr5m+7jStPYExAvjXkEz/FBD/uHB1XqW+Pi8vAfkur1utMdcE LXYr2khRAajYxHYikGjAJxN92NBYDyIK0jhlmPs7CwGSMPZH9wJhax2Jj61MYKp5 zHItKmdUq81DN/v1CRkzN7bGwBGC+mzCQxkXBzhpSR9WG6/ry6S1dKsSMFXmbB4= =QKem -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Apr 12 21:14:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A5AC2C5 for ; Fri, 12 Apr 2013 21:14:19 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by mx1.freebsd.org (Postfix) with ESMTP id E08011DB7 for ; Fri, 12 Apr 2013 21:14:18 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 14so271868vea.29 for ; Fri, 12 Apr 2013 14:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sGP5PiXfoCIZrQ7i7M9IE6oQjQzbiBDx+KDg9gU1a6k=; b=zbOmknFsRj2oC3HNx99GkZ1rezfGN1bmu6j/MAPuquGh7T8iPI73Q8/Nw1dvK8cW5I HjnZ7L/N0xV984Ock8TKhdxgWy4Ug++JqwxjLMR4Ayg1cX8gUo+IU7GnALPwi1Nfq10O V6w67y5oj25UwFRHhuOE9K5U64+Bwf9GOVxvI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sGP5PiXfoCIZrQ7i7M9IE6oQjQzbiBDx+KDg9gU1a6k=; b=OXU1801LkZuG77Nz9SD+xw+oafhXkKTN/m9ffJ9kdFOAuxAYO1gy8j7TdfEYMsGxw6 16HC/6Ec07mu/sfOvAQuMpGf8uJ/r8eUrgtbJ+4Y8zOL5LR2EiCqoSHrDWghvFFej59d vGgl5Sps6f/p1Fq1Hhynzq/6/UayxBMDn2/5/VjCrDJQyIEJDDV+Yt+yWsfF9AUy3NQj LRTe9QTlzGegver3xij4ishR1HwBEdZCyIYCuUOuKzYw8wkxo+M3qgsAii6UFgZctXui ohq8U/CHJG2jK7DaPhafB0LePUWM/dAuW8mmvHkz2JCLMttZS+FP8WDPAvGp8aZjU0uX dxyQ== MIME-Version: 1.0 X-Received: by 10.52.174.196 with SMTP id bu4mr8226014vdc.117.1365801257867; Fri, 12 Apr 2013 14:14:17 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 12 Apr 2013 14:14:17 -0700 (PDT) In-Reply-To: <1365800188.1418.29.camel@localhost> References: <1365800188.1418.29.camel@localhost> Date: Fri, 12 Apr 2013 14:14:17 -0700 Message-ID: Subject: Re: bce(4) on the Dell PE 2950 From: Peter Wemm To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQllkatAeNdawbvpnf9oOS0kLegJcvuzHr2AQLuU6reujoBBg0JWydLdQR05lk5TzOjoNBpK Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:14:19 -0000 On Fri, Apr 12, 2013 at 1:56 PM, Sean Bruno wrote: > A note from clusteradm@freebsd.org > > It looks like there is some amount of instability or bugginess in some > of the Broadcom firmware(management) on the bce(4) chipeset shipped on > later generations of the Poweredge 2950 from Dell: > > bce0: > > Specifically, we've seen that newer (9 and higher) have issues with the > doing initial setup and negotiation and that Dell did indeed release > newer firmware to fix the issues. This requires a full reboot into > Linux (probably centos6) to get the update to execute. > > Sean More specifically.. this is the problematic revision: bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (2.9.1); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) and the upgrade takes you to bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) If you're seeing things like: bce0: ../../../dev/bce/if_bce.c(7906): Watchdog timeout occurred, resetting! over and over, then this would be a good thing to update. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 01:43:21 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0F97E6D; Sat, 13 Apr 2013 01:43:21 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id AF8918C0; Sat, 13 Apr 2013 01:43:21 +0000 (UTC) Received: from [IPv6:2601:9:4d00:3c:b4f2:b05c:fbbb:d700] (unknown [IPv6:2601:9:4d00:3c:b4f2:b05c:fbbb:d700]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 8FDEB3981E; Fri, 12 Apr 2013 18:43:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Rui Paulo In-Reply-To: <20130411201805.GD76816@FreeBSD.org> Date: Fri, 12 Apr 2013 18:43:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> References: <20130411201805.GD76816@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1503) Cc: current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 01:43:21 -0000 On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > Lack of maintainer in a near future would lead to bitrot due to = changes > in other areas of network stack, kernel APIs, etc. This already = happens, > many changes during 10.0-CURRENT cycle were only compile tested wrt > ipfilter. If we fail to find maintainer, then a correct decision would = be > to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said = "I'm still using ipfilter!" and the idea to remove it dies with it.=20 I've been saying we should remove it for 4 years now. Not only it's = outdated but it also doesn't not fit well in the FreeBSD roadmap. Then = there's the question of maintainability. We gave the author a commit bit = so that he could maintain it. That doesn't happen anymore and it sounds = like he has since moved away from FreeBSD. I cannot find any reason to = burden another FreeBSD developer with maintaining ipfilter. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 02:49:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C3F87EC for ; Sat, 13 Apr 2013 02:49:04 +0000 (UTC) (envelope-from surajsandhu.bsd@gmail.com) Received: from mail-qc0-x243.google.com (mail-qc0-x243.google.com [IPv6:2607:f8b0:400d:c01::243]) by mx1.freebsd.org (Postfix) with ESMTP id C8B65A46 for ; Sat, 13 Apr 2013 02:49:03 +0000 (UTC) Received: by mail-qc0-f195.google.com with SMTP id e18so2509qch.2 for ; Fri, 12 Apr 2013 19:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=14EojoM8CiuQQIl0+TGjk/IOOFdgMpXbfYIn9p27m9E=; b=y9ICZ2KNbAoNZtwU3pbshjEcwX9BzDVfTtwexxx11T826/q9D7HVW1SPsHX3fhHti0 Z7QA8bmENHEJiOP1okRRM4Iy28Ng6W67lN+7Z9v/UkSlE6t7YNWaMVGkdvqc+Hu2zZPx RaZz2ln6CNXJXVmKnPS4elSPiAZNmLoMgLFCEtmmwzhif7gPBDaeRycDS6DZhjoQpTjE boxhyZ93u/XeL6uZYp/46RgJEoVHP2PNWy43LEbzzF8ACLzXQuyslRF5s9PYm6lSGx6T M1M++PrDhm9jWsr5MykJjflyOwTsPdFqqifb+Y1iIMLloS8IXp5rFapkPXHqassVVpRI ZEBg== MIME-Version: 1.0 X-Received: by 10.49.106.40 with SMTP id gr8mr14927007qeb.42.1365821343247; Fri, 12 Apr 2013 19:49:03 -0700 (PDT) Received: by 10.229.112.29 with HTTP; Fri, 12 Apr 2013 19:49:03 -0700 (PDT) Date: Fri, 12 Apr 2013 22:49:03 -0400 Message-ID: Subject: Race condition inside if_detach_internal() leads to a crash while running "jail -r" From: suraj sandhu To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 02:49:04 -0000 I am running FreeBsd 8.2 and hitting this panic: kdb_backtrace() at kdb_backtrace+0x3e panic() at panic+0x479 trap_fatal() at trap_fatal+0x4f4 trap() at trap+0x8fe calltrap() at calltrap+0x8 --- trap 0x9, rip = 0xffffffff80518f4d, rsp = 0xffffff805fa1d9e0, rbp = 0xffffff805fa1da30 --- raw_input() at raw_input+0x4d rts_input() at rts_input+0x70 netisr_process_workstream_proto() at netisr_process_workstream_proto+0x1ea swi_net() at swi_net+0xad intr_event_execute_handlers() at intr_event_execute_handlers+0x21c ithread_execute_handlers() at ithread_execute_handlers+0x73 ithread_loop() at ithread_loop+0x10f fork_exit() at fork_exit+0x180 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff805fa1dd30, rbp = 0 --- Uptime: 20h23m27s I looked into the code and issue seems to be that in if_detach_internal(), if_down() is called which leads to netisr_queue() call in rt_dispatch() with an mbuf which has the interface being detached as rcvif, subsequently if_detach_internal() calls if_dead() on the interface. And, then at time of processing the work, this panic is seen since mbuf has a dead interface. Seems like the issue was reported on the virtualization mailing list earlier: http://lists.freebsd.org/pipermail/freebsd-virtualization/2012-April/000885.html I am looking for patch(es) to fix this issue. Thanks for any help. -Suraj Sandhu From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 05:57:50 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43C16B3B; Sat, 13 Apr 2013 05:57:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EBBCEC2; Sat, 13 Apr 2013 05:57:49 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r3D5V9B7089041; Fri, 12 Apr 2013 23:31:09 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> Date: Fri, 12 Apr 2013 23:31:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> To: Rui Paulo , Gleb Smirnoff X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 05:57:50 -0000 On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >=20 >> Lack of maintainer in a near future would lead to bitrot due to = changes >> in other areas of network stack, kernel APIs, etc. This already = happens, >> many changes during 10.0-CURRENT cycle were only compile tested wrt >> ipfilter. If we fail to find maintainer, then a correct decision = would be >> to remove ipfilter(4) from the base system before 10.0-RELEASE. >=20 > This has been discussed in the past. Every time someone came up and = said "I'm still using ipfilter!" and the idea to remove it dies with it.=20= > I've been saying we should remove it for 4 years now. Not only it's = outdated but it also doesn't not fit well in the FreeBSD roadmap. Then = there's the question of maintainability. We gave the author a commit bit = so that he could maintain it. That doesn't happen anymore and it sounds = like he has since moved away from FreeBSD. I cannot find any reason to = burden another FreeBSD developer with maintaining ipfilter. >=20 One thing that FreeBSD is bad about (and this really applies to many = open source projects) when deprecating something is that the developer = and release engineering groups rarely provide adequate, if any, tools to = help users transition and cope with the deprecation. The fear of = deprecation can be largely overcome by giving these users a clear and = comprehensive path forward. Just announcing "ipfilter is going away. = EOM" is inadequate and leads to completely justified complaints from = users. So with that said, would it be possible to write some tutorials on how = to migrate an ipfilter installation to pf? Maybe some mechanical syntax = docs accompanied by a few case studies? Is it possible for a script to = automate some of the common mechanical changes? Also essential is a = clear document on what goes away with ipfilter and what is gained with = pf. Once those tools are written, I suggest announcing that ipfilter is = available but deprecated/unsupported in FreeBSD 10, and will be removed = from FreeBSD 11. Certain people will still pitch a fit about it = departing, but if the tools are there to help the common users, you'll = be successful in winning mindshare and general support. Scott From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 06:22:28 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4D4EEE8F; Sat, 13 Apr 2013 06:22:28 +0000 (UTC) (envelope-from john@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 3672E178; Sat, 13 Apr 2013 06:22:27 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id D709762035; Fri, 12 Apr 2013 23:22:26 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 13228-08; Fri, 12 Apr 2013 23:22:18 -0700 (PDT) Received: from thinkbsd.divinix.org (unknown [10.8.0.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id E1F3B6202F; Fri, 12 Apr 2013 23:22:17 -0700 (PDT) Date: Fri, 12 Apr 2013 23:22:16 -0700 From: John Hixson To: Scott Long Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130413062215.GD38195@thinkbsd.divinix.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rui Paulo , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 06:22:28 -0000 On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: > > On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > > > On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > > > >> Lack of maintainer in a near future would lead to bitrot due to changes > >> in other areas of network stack, kernel APIs, etc. This already happens, > >> many changes during 10.0-CURRENT cycle were only compile tested wrt > >> ipfilter. If we fail to find maintainer, then a correct decision would be > >> to remove ipfilter(4) from the base system before 10.0-RELEASE. > > > > This has been discussed in the past. Every time someone came up and said "I'm still using ipfilter!" and the idea to remove it dies with it. > > I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. > > > > One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing "ipfilter is going away. EOM" is inadequate and leads to completely justified complaints from users. > > So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. > ++ From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 06:33:32 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79912120; Sat, 13 Apr 2013 06:33:32 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 66C651C9; Sat, 13 Apr 2013 06:33:32 +0000 (UTC) Received: from [IPv6:2601:9:4d00:3c:b4f2:b05c:fbbb:d700] (unknown [IPv6:2601:9:4d00:3c:b4f2:b05c:fbbb:d700]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 0CFFB3981E; Fri, 12 Apr 2013 23:33:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Rui Paulo In-Reply-To: Date: Fri, 12 Apr 2013 23:33:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> To: Scott Long X-Mailer: Apple Mail (2.1503) Cc: current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 06:33:32 -0000 On 2013/04/12, at 22:31, Scott Long wrote: > On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >=20 >> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>=20 >>> Lack of maintainer in a near future would lead to bitrot due to = changes >>> in other areas of network stack, kernel APIs, etc. This already = happens, >>> many changes during 10.0-CURRENT cycle were only compile tested wrt >>> ipfilter. If we fail to find maintainer, then a correct decision = would be >>> to remove ipfilter(4) from the base system before 10.0-RELEASE. >>=20 >> This has been discussed in the past. Every time someone came up and = said "I'm still using ipfilter!" and the idea to remove it dies with it.=20= >> I've been saying we should remove it for 4 years now. Not only it's = outdated but it also doesn't not fit well in the FreeBSD roadmap. Then = there's the question of maintainability. We gave the author a commit bit = so that he could maintain it. That doesn't happen anymore and it sounds = like he has since moved away from FreeBSD. I cannot find any reason to = burden another FreeBSD developer with maintaining ipfilter. >>=20 >=20 > One thing that FreeBSD is bad about (and this really applies to many = open source projects) when deprecating something is that the developer = and release engineering groups rarely provide adequate, if any, tools to = help users transition and cope with the deprecation. The fear of = deprecation can be largely overcome by giving these users a clear and = comprehensive path forward. Just announcing "ipfilter is going away. = EOM" is inadequate and leads to completely justified complaints from = users. I agree with the deprecation path, but given the amount of changes that = happened in the last 6 months, I'm not even sure ipfilter is working = fine in FreeBSD CURRENT, but I haven't tested it. > So with that said, would it be possible to write some tutorials on how = to migrate an ipfilter installation to pf? Maybe some mechanical syntax = docs accompanied by a few case studies? Is it possible for a script to = automate some of the common mechanical changes? Also essential is a = clear document on what goes away with ipfilter and what is gained with = pf. Once those tools are written, I suggest announcing that ipfilter is = available but deprecated/unsupported in FreeBSD 10, and will be removed = from FreeBSD 11. Certain people will still pitch a fit about it = departing, but if the tools are there to help the common users, you'll = be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, = but I'm not sure automated tools exist. I'm also not convinced we need = to write them and I think the issue can be deal with by writing a bunch = of examples on how to do it manually. Then we can give people 1y to = switch. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 10:07:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7FD52326; Sat, 13 Apr 2013 10:07:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.freebsd.org (Postfix) with ESMTP id 05E8BAD2; Sat, 13 Apr 2013 10:07:04 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail27.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3DA6u8l000792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Apr 2013 20:06:57 +1000 Date: Sat, 13 Apr 2013 20:06:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sbruno@freebsd.org Subject: Re: bge(4) sysctl tuneables -- a blast from the past. In-Reply-To: <1365781568.1418.1.camel@localhost> Message-ID: <20130413200512.G1165@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=S7iBW/QP c=1 sm=1 a=vYrNp6gXSs8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=_Js9cBt6JEEA:10 a=yON4etAAAAAA:8 a=V6Bi3Rr-7P1LahlmEawA:9 a=CjuIK1q_8ugA:10 a=pc2dg7cbpYUA:10 a=H3lsIFeUpAwA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , bde@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 10:07:05 -0000 On Fri, 12 Apr 2013, Sean Bruno wrote: > http://markmail.org/message/brpfcifnf2742pff > > So, these never happened. *sigh* > > I think they should. Any objections? FreeBSD has too many knobs, but it would be nice if the bge defaults weren't so broken, so that they don't need overriding. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 12:03:46 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62E6C9ED; Sat, 13 Apr 2013 12:03:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2585A8D; Sat, 13 Apr 2013 12:03:45 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r3DC3gmX092052; Sat, 13 Apr 2013 06:03:42 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> Date: Sat, 13 Apr 2013 06:03:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> To: Rui Paulo , Gleb Smirnoff X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 12:03:46 -0000 On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote: > On 2013/04/12, at 22:31, Scott Long wrote: >=20 >> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>=20 >>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>>=20 >>>> Lack of maintainer in a near future would lead to bitrot due to = changes >>>> in other areas of network stack, kernel APIs, etc. This already = happens, >>>> many changes during 10.0-CURRENT cycle were only compile tested wrt >>>> ipfilter. If we fail to find maintainer, then a correct decision = would be >>>> to remove ipfilter(4) from the base system before 10.0-RELEASE. >>>=20 >>> This has been discussed in the past. Every time someone came up and = said "I'm still using ipfilter!" and the idea to remove it dies with it.=20= >>> I've been saying we should remove it for 4 years now. Not only it's = outdated but it also doesn't not fit well in the FreeBSD roadmap. Then = there's the question of maintainability. We gave the author a commit bit = so that he could maintain it. That doesn't happen anymore and it sounds = like he has since moved away from FreeBSD. I cannot find any reason to = burden another FreeBSD developer with maintaining ipfilter. >>>=20 >>=20 >> One thing that FreeBSD is bad about (and this really applies to many = open source projects) when deprecating something is that the developer = and release engineering groups rarely provide adequate, if any, tools to = help users transition and cope with the deprecation. The fear of = deprecation can be largely overcome by giving these users a clear and = comprehensive path forward. Just announcing "ipfilter is going away. = EOM" is inadequate and leads to completely justified complaints from = users. >=20 > I agree with the deprecation path, but given the amount of changes = that happened in the last 6 months, I'm not even sure ipfilter is = working fine in FreeBSD CURRENT, but I haven't tested it. >=20 You target audience for this isn't people who track CURRENT, it's people = who are on 7, 8, or 9 and looking to update to 10.x sometime in the = future. >> So with that said, would it be possible to write some tutorials on = how to migrate an ipfilter installation to pf? Maybe some mechanical = syntax docs accompanied by a few case studies? Is it possible for a = script to automate some of the common mechanical changes? Also = essential is a clear document on what goes away with ipfilter and what = is gained with pf. Once those tools are written, I suggest announcing = that ipfilter is available but deprecated/unsupported in FreeBSD 10, and = will be removed from FreeBSD 11. Certain people will still pitch a fit = about it departing, but if the tools are there to help the common users, = you'll be successful in winning mindshare and general support. >=20 >=20 > It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, = but I'm not sure automated tools exist. I'm also not convinced we need = to write them and I think the issue can be deal with by writing a bunch = of examples on how to do it manually. Then we can give people 1y to = switch. >=20 Please believe me that no matter how trivial you think the switch is, a = migration guide still needs to be written. Scott \= From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 12:13:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D4B8D1F; Sat, 13 Apr 2013 12:13:41 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 27366135; Sat, 13 Apr 2013 12:13:39 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so323060wib.4 for ; Sat, 13 Apr 2013 05:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ncYewNEqrVoGG7rIJVc4pIHBCTO9DfUhoKivuz/yyhs=; b=lKk92uQfzEcseCH1ZBVPskCAxCUhsoTbVf27ftWXZ1UCir+AhUOf5f8wHrfXTQodjY uRs7RLfj3pKZXl/GYfndAtGdXWNAw6ExwRVihxltM7aO7GU6p4Wl4ufMlmzfJKXpvZMa FfoZlOAabkmMANCsPXt50D2y3rDHrr8rPch1sv9jhtC7OyHytxfyGF53YelTAKPD8DVJ LUOaoyYUDjTKVPzuaSB7DjHEH3zj4spS/hfzACj3z2q2xzlaKtMnVYix8E7uNfUGu3+D v0s8MuGp4Rqm1nNrvWkr/+QlSrkQtS7OI0VM1KqBHpOX4d94tP60+luejKWbY1xSWf4g KLIA== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr2869930wiv.27.1365855219275; Sat, 13 Apr 2013 05:13:39 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sat, 13 Apr 2013 05:13:39 -0700 (PDT) In-Reply-To: <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> Date: Sat, 13 Apr 2013 15:13:39 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 12:13:41 -0000 On Sat, Apr 13, 2013 at 3:03 PM, Scott Long wrote: > > On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote: > >> On 2013/04/12, at 22:31, Scott Long wrote: >> >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>> >>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>>> >>>>> Lack of maintainer in a near future would lead to bitrot due to chang= es >>>>> in other areas of network stack, kernel APIs, etc. This already happe= ns, >>>>> many changes during 10.0-CURRENT cycle were only compile tested wrt >>>>> ipfilter. If we fail to find maintainer, then a correct decision woul= d be >>>>> to remove ipfilter(4) from the base system before 10.0-RELEASE. >>>> >>>> This has been discussed in the past. Every time someone came up and sa= id "I'm still using ipfilter!" and the idea to remove it dies with it. >>>> I've been saying we should remove it for 4 years now. Not only it's ou= tdated but it also doesn't not fit well in the FreeBSD roadmap. Then there'= s the question of maintainability. We gave the author a commit bit so that = he could maintain it. That doesn't happen anymore and it sounds like he has= since moved away from FreeBSD. I cannot find any reason to burden another = FreeBSD developer with maintaining ipfilter. >>>> >>> >>> One thing that FreeBSD is bad about (and this really applies to many op= en source projects) when deprecating something is that the developer and re= lease engineering groups rarely provide adequate, if any, tools to help use= rs transition and cope with the deprecation. The fear of deprecation can b= e largely overcome by giving these users a clear and comprehensive path for= ward. Just announcing "ipfilter is going away. EOM" is inadequate and lea= ds to completely justified complaints from users. >> >> I agree with the deprecation path, but given the amount of changes that = happened in the last 6 months, I'm not even sure ipfilter is working fine i= n FreeBSD CURRENT, but I haven't tested it. >> > > You target audience for this isn't people who track CURRENT, it's people = who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. > >>> So with that said, would it be possible to write some tutorials on how = to migrate an ipfilter installation to pf? Maybe some mechanical syntax do= cs accompanied by a few case studies? Is it possible for a script to autom= ate some of the common mechanical changes? Also essential is a clear docum= ent on what goes away with ipfilter and what is gained with pf. Once those= tools are written, I suggest announcing that ipfilter is available but dep= recated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Ce= rtain people will still pitch a fit about it departing, but if the tools ar= e there to help the common users, you'll be successful in winning mindshare= and general support. >> >> >> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, b= ut I'm not sure automated tools exist. I'm also not convinced we need to wr= ite them and I think the issue can be deal with by writing a bunch of examp= les on how to do it manually. Then we can give people 1y to switch. >> > > Please believe me that no matter how trivial you think the switch is, a m= igration guide still needs to be written. > > Scott > \ The migration guide is best written by the current users of ipfilter, not those who have no interest in doing so because their interests are completely elsewhere. Please don't try to defer to an authority that does not exist here. -Kimmo From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 17:34:17 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D015681; Sat, 13 Apr 2013 17:34:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id BF1CCD2A; Sat, 13 Apr 2013 17:34:15 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3DHY7HU083536; Sat, 13 Apr 2013 21:34:07 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3DHY7v0083535; Sat, 13 Apr 2013 21:34:07 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 13 Apr 2013 21:34:07 +0400 From: Gleb Smirnoff To: Scott Long Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130413173407.GY76816@glebius.int.ru> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rui Paulo , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 17:34:17 -0000 Scott, On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: S> One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing "ipfilter is going away. EOM" is inadequate and leads to completely justified complaints from users. S> S> So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. The task to write a migration guide is already a task for maintainer, and the thread is to search one. If lack of migration guide doesn't allow us to remove in 10.x cycle, I doubt the guide will appear in 11.x cycle, 12.x, etc. So we will live with ipfilter forever. What I can do, is to resend email to the stable@ list. Also, I can add the deprecation WARNING to stable/9 unless we find maintainer prior to 9.2 branching. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 17:43:19 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A78F4A8C; Sat, 13 Apr 2013 17:43:19 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9166DDC3; Sat, 13 Apr 2013 17:43:19 +0000 (UTC) Received: from [IPv6:2601:9:4d00:3c:551a:f107:2184:3cc5] (unknown [IPv6:2601:9:4d00:3c:551a:f107:2184:3cc5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id A8BF33981E; Sat, 13 Apr 2013 10:43:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Rui Paulo In-Reply-To: <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> Date: Sat, 13 Apr 2013 10:43:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> To: Scott Long X-Mailer: Apple Mail (2.1503) Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 17:43:19 -0000 On 2013/04/13, at 5:03, Scott Long wrote: > You target audience for this isn't people who track CURRENT, it's = people who are on 7, 8, or 9 and looking to update to 10.x sometime in = the future. Yes, I'm aware of that, but the problem remains. If ipfilter is broken = or gets broken because of the networking stack changes, we'll have to = fix it to keep the deprecation path going... >>> So with that said, would it be possible to write some tutorials on = how to migrate an ipfilter installation to pf? Maybe some mechanical = syntax docs accompanied by a few case studies? Is it possible for a = script to automate some of the common mechanical changes? Also = essential is a clear document on what goes away with ipfilter and what = is gained with pf. Once those tools are written, I suggest announcing = that ipfilter is available but deprecated/unsupported in FreeBSD 10, and = will be removed from FreeBSD 11. Certain people will still pitch a fit = about it departing, but if the tools are there to help the common users, = you'll be successful in winning mindshare and general support. >>=20 >>=20 >> It's not very difficult to switch an ipf.conf/ipnat.conf to a = pf.conf, but I'm not sure automated tools exist. I'm also not convinced = we need to write them and I think the issue can be deal with by writing = a bunch of examples on how to do it manually. Then we can give people 1y = to switch. >>=20 >=20 > Please believe me that no matter how trivial you think the switch is, = a migration guide still needs to be written. A migration *guide*, yes. Tools to convert one syntax to another: no. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Apr 13 23:01:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8756718A for ; Sat, 13 Apr 2013 23:01:31 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm19.bullet.mail.bf1.yahoo.com (nm19.bullet.mail.bf1.yahoo.com [98.139.212.178]) by mx1.freebsd.org (Postfix) with SMTP id 2A3E91703 for ; Sat, 13 Apr 2013 23:01:31 +0000 (UTC) Received: from [98.139.215.143] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 Received: from [76.13.13.228] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 Received: from [127.0.0.1] by smtp107-mob.biz.mail.ac4.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365894090; bh=MB77me6FnuoXHyzsbc1NiiiUuXBdLnyjmV9Rp3CiesM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=LWrQLzEuSIBO1WBLNUYzWTxkW7FjY4lmOFfNUw3ys1/9qwhJ1VSragX1EgtD6ealPYCm2PL8dbbeYgm5cmIS/YHplj/NFAKEY2rbgsHeLPQ7e3qKGsjKUkdQxAm91gIR7V2EBJblxeknQq7KZezzOKnFdVY9Un/w5+kQ8kNRmEc= X-Yahoo-Newman-Id: 345441.26413.bm@smtp107-mob.biz.mail.ac4.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Mu3qXagVM1mdY3BXwVvJdbJUVa2H2gL41i2RNLg05aCBpnd 3_UdCuRRAFR5VgIuehgNHl.rdN0vFOY7ygp9uM0YgupuxizNPg0cYFigZdSn r8lOmR6gjD13wsZQZK.wNa9kou.4NUQG0OrfkpEUXTJGPXSl6d5Vog4sLbdH tBp4EasnWpXtXL28G203PjEJj914NfbJGIA00noKyVSK1SxDpOHr4RJ1YquV dYkWXedF7SWDTXGsnjhmMp_FpBhInLAxR61ZXfuGU3hTYIY3.pdn_yXDxl_o tgsKnvt6c1iZNfF0wosKZJ0MzhRfKCdXkV6O6maHoAJSxB4ihw9qdGVYd066 5Aikl.exTa5vltaKpjzoewWYYaV5Cc8hWTyrkRep9Z7hpcJhwd_ZPnb0sDSI 3P9h12k52cyfsmetbYSn3WdYPIbVdh_E_ZMzwODRFhAJhylq5eECmNDkWlT3 EfR5rlYkd0kjRy.0USck1dK0_ZSlMeydb X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.184.10.106] (scott4long@70.196.197.242 with xymcookie) by smtp107-mob.biz.mail.ac4.yahoo.com with SMTP; 13 Apr 2013 16:01:30 -0700 PDT References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> X-Mailer: iPhone Mail (10B329) From: Scott Long Subject: Re: ipfilter(4) needs maintainer Date: Sat, 13 Apr 2013 17:01:29 -0600 To: Rui Paulo Cc: Scott Long , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 23:01:31 -0000 On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote: > On 2013/04/13, at 5:03, Scott Long wrote: >> You target audience for this isn't people who track CURRENT, it's people w= ho are on 7, 8, or 9 and looking to update to 10.x sometime in the future. >=20 > Yes, I'm aware of that, but the problem remains. If ipfilter is broken or g= ets broken because of the networking stack changes, we'll have to fix it to k= eep the deprecation path going... >=20 Welcome to the challenges of maintaining a whole OS :-) >>>> So with that said, would it be possible to write some tutorials on how t= o migrate an ipfilter installation to pf? Maybe some mechanical syntax docs= accompanied by a few case studies? Is it possible for a script to automate= some of the common mechanical changes? Also essential is a clear document o= n what goes away with ipfilter and what is gained with pf. Once those tools= are written, I suggest announcing that ipfilter is available but deprecated= /unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain pe= ople will still pitch a fit about it departing, but if the tools are there t= o help the common users, you'll be successful in winning mindshare and gener= al support. >>>=20 >>>=20 >>> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, b= ut I'm not sure automated tools exist. I'm also not convinced we need to wri= te them and I think the issue can be deal with by writing a bunch of example= s on how to do it manually. Then we can give people 1y to switch. >>=20 >> Please believe me that no matter how trivial you think the switch is, a m= igration guide still needs to be written. >=20 >=20 > A migration *guide*, yes. Tools to convert one syntax to another: no. >=20 Ok, so in response to this and to Glebs email, lets rephrase the call for he= lp into a call for someone with ipfilter experience to help write a migratio= n guide. Like I said, this isn't about migrating from 10-current to 10-curr= ent prime, it about migrating from 7/8/9 where up ipfilter does work. Maybe= look for old openbsd docs and mailing list items from when they did their f= orced migration. Maybe fish for help by announcing the deprecation and remo= val schedule and hook whomever complains into helping instead. Maybe someth= ing else, but whatever it is, it should be done. If you and Gleb don't want= to do this, I will. Scott