From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:51:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D7710656D8 for ; Sun, 20 Feb 2011 23:51:29 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id D6D158FC17 for ; Sun, 20 Feb 2011 23:51:28 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrJ3o-000Gqd-5a for freebsd-net@freebsd.org; Mon, 21 Feb 2011 00:51:28 +0100 Date: Mon, 21 Feb 2011 00:50:50 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <455301788.20110221005050@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220235540.GA10655@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> <20110220231825.GA10566@onelab2.iet.unipi.it> <1167743969.20110221001312@nitronet.pl> <20110220235540.GA10655@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Feb 2011 23:51:29 -0000 > addresses not needed, thanks. From what i saw in the backtrace, the panic > occurred on an incoming packet on the 'antispoof' option. > The ruleset confirms the backtrace, but since > 'antispoof' happens > to be run on every packet given it is on the first rule, > it apparently has nothing to do with dummynet because even if > you reinjected the packets, they go to rule 34900. > So, i'd still focus the attention on a corrupt interface list. > Sure, that memory can be corrupt by anything including dummynet, > but there is no reason to believe that dummynet is more likely > than other subsystems to cause the breakage. > Unfortunately i don't think I can be of more help. Actually that's a lot of help: new thing to try. I've removed the antispoof rule and automatic reboot. Lets see what comes out of it.