From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 00:39:10 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37B30106564A for ; Sun, 20 Feb 2011 00:39:10 +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 E83D18FC16 for ; Sun, 20 Feb 2011 00:39:09 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqxKO-000NhK-Bw for freebsd-ipfw@freebsd.org; Sun, 20 Feb 2011 01:39:08 +0100 Date: Sun, 20 Feb 2011 01:39:00 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <410175608.20110220013900@nitronet.pl> To: Jack Vogel , Brandon Gooch , Luigi Rizzo , , 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: Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 00:39:10 -0000 Hi guys, lists, It's me, the bi-weekly panic guy. Guess what, it crashed today. As an act of desperation I disabled the pipe dumping script after previous crash, which today turned out to be merely a coincidence and didn't prevent panics. (I thought it to be a longshot anyway, but it was the only change I could associate with beginning of this). The only fix I could come up with, that's very wrong on so many levels, is... 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." :( ...but it solves it all: panics, inability to dump (which leads to freeze and requires manual intervention to bring system back up). Oh well. Since nobody came up with any interest in having this properly investigated, then I suppose I'm the only one that uses dummynet for some larger-scale traffic shaping - maybe that's my mistake? What others are using? Other tools, Linux, proprietary traffic shapers? I really have trouble writing another sentence in a way that won't make me look like an arrogant schmuck that feels entitled to free support, so I'll stop here. Any more ideas/hints what to do next/pointers how to debug this properly are of course still welcome. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 02:16:09 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB758106564A; Sun, 20 Feb 2011 02:16:09 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 397AC8FC0A; Sun, 20 Feb 2011 02:16:09 +0000 (UTC) Received: by wyb32 with SMTP id 32so778680wyb.13 for ; Sat, 19 Feb 2011 18:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pUjBeBuXNG+Cpy4EH8113mhlvhl74esZ6CcNcmrDn3w=; b=scnPmIi4fMoQ8QUeeVUGYjRcMEodUTpw7bao2Ab44oW5ZfweSYIT8gWaKuog3DKoj7 pSSWSQKRbipQTN/mu/v3Cv6BHp47m7ahlFvElWD1TwcPTXdGkAcFKZsPIoxt+rsG3xh0 Ho7cGMZSXf3LZ1xZDwkZGfDoiemf61QgwDq8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uYCsrxKsGdhMkNhc3xuJbAAjN6thI3vaK4fVORExtkj9oBM25TgPrXub0HRZr5GBJu u0W4yn9HssXZHUdIRHi+QStF9srThGeOde6GYDIBac6KbRv7Fakqkie4dWXNWKAOdxEU 4WkAZ6lBx1jG9N7CB/YEG2P3Cpdl+yZPcdJiA= MIME-Version: 1.0 Received: by 10.216.150.129 with SMTP id z1mr1910577wej.113.1298168168046; Sat, 19 Feb 2011 18:16:08 -0800 (PST) Received: by 10.216.244.130 with HTTP; Sat, 19 Feb 2011 18:16:08 -0800 (PST) In-Reply-To: <410175608.20110220013900@nitronet.pl> References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 20:16:08 -0600 Message-ID: From: Brandon Gooch To: Pawel Tyll Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 02:16:09 -0000 2011/2/19 Pawel Tyll : > Hi guys, lists, > > It's me, the bi-weekly panic guy. Guess what, it crashed today. As an > act of desperation I disabled the pipe dumping script after previous > crash, which today turned out to be merely a coincidence and didn't > prevent panics. (I thought it to be a longshot anyway, but it was the > only change I could associate with beginning of this). The only fix I > could come up with, that's very wrong on so many levels, is... > > 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." > > :( > > ...but it solves it all: panics, inability to dump (which leads to > freeze and requires manual intervention to bring system back up). Oh > well. > > Since nobody came up with any interest in having this properly > investigated, then I suppose I'm the only one that uses dummynet for > some larger-scale traffic shaping - maybe that's my mistake? What > others are using? Other tools, Linux, proprietary traffic shapers? I > really have trouble writing another sentence in a way that won't make > me look like an arrogant schmuck that feels entitled to free support, > so I'll stop here. Any more ideas/hints what to do next/pointers how > to debug this properly are of course still welcome. Same backtrace as reported here? http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 What revision of the em(4) driver code are you using? I know Jack has been working out certain quirky issues lately, and there have been updates to the code since last you posted an update to your problem. STABLE: http://svn.freebsd.org/viewvc/base?view=revision&revision=217711 RELENG: http://svn.freebsd.org/viewvc/base?view=revision&revision=217865 Maybe Jack could shed some light on the whether the updates could somehow work out to be a fix for your problem -- or whether or not your issue is even related to the em(4) driver. -Brandon From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 02:40:09 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9FE9106564A; Sun, 20 Feb 2011 02:40:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78BEB8FC08; Sun, 20 Feb 2011 02:40:09 +0000 (UTC) Received: by vxa40 with SMTP id 40so2805907vxa.13 for ; Sat, 19 Feb 2011 18:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3LwggtY88fi/XzOy000iC9l5qKGTjuw7dEDUk2DzSG0=; b=DMrBhZizShYrWav5qGW3JL6Wv2N0Mq/tg6JLAMcxOQvxnkn5YwtOagag8EOveYTlKq CvNEkLEVFlFeY86xPcFyJcRV8MlIyjebAivAdU2OTTeLBGvyYFUV8U/O31HHI1ExadzY FiIpn6HA3tEB0BKqV2KtnkCEAzxwWAk3PD1zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UDnUA/ho1RACWn71+4YqwWmzosfjSZv6d6XXGCxHHIhsHiq7833ARa8kFaurbE3M1f TWeRbGzoBRo4olltQyUJQEkBDnWzrHwKlhvwApCjvB9zX8Fwz2k09zgWwZys3sjFcTAF 00CtuLY0JCvcwkxAq6lp9Y3C8x2tedRgTMLbM= MIME-Version: 1.0 Received: by 10.52.165.136 with SMTP id yy8mr3951665vdb.68.1298169608385; Sat, 19 Feb 2011 18:40:08 -0800 (PST) Received: by 10.52.160.5 with HTTP; Sat, 19 Feb 2011 18:40:08 -0800 (PST) In-Reply-To: References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 18:40:08 -0800 Message-ID: From: Jack Vogel To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Tyll , freebsd-net@freebsd.org, Luigi Rizzo , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 02:40:09 -0000 I've never seen a trace like this, and no absolutely nothing about dummynet, sorry. If it is in some way em's fault, then making sure you have the latest code would be a good idea. I have a test driver that is under selective test, it does effect the code path that you seem to be in, so it might be worth a try. If you want to try it early just pipe up and I'll send it. Jack On Sat, Feb 19, 2011 at 6:16 PM, Brandon Gooch wrote: > 2011/2/19 Pawel Tyll : > > Hi guys, lists, > > > > It's me, the bi-weekly panic guy. Guess what, it crashed today. As an > > act of desperation I disabled the pipe dumping script after previous > > crash, which today turned out to be merely a coincidence and didn't > > prevent panics. (I thought it to be a longshot anyway, but it was the > > only change I could associate with beginning of this). The only fix I > > could come up with, that's very wrong on so many levels, is... > > > > 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." > > > > :( > > > > ...but it solves it all: panics, inability to dump (which leads to > > freeze and requires manual intervention to bring system back up). Oh > > well. > > > > Since nobody came up with any interest in having this properly > > investigated, then I suppose I'm the only one that uses dummynet for > > some larger-scale traffic shaping - maybe that's my mistake? What > > others are using? Other tools, Linux, proprietary traffic shapers? I > > really have trouble writing another sentence in a way that won't make > > me look like an arrogant schmuck that feels entitled to free support, > > so I'll stop here. Any more ideas/hints what to do next/pointers how > > to debug this properly are of course still welcome. > > Same backtrace as reported here? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 > > What revision of the em(4) driver code are you using? I know Jack has > been working out certain quirky issues lately, and there have been > updates to the code since last you posted an update to your problem. > > STABLE: > http://svn.freebsd.org/viewvc/base?view=revision&revision=217711 > > RELENG: > http://svn.freebsd.org/viewvc/base?view=revision&revision=217865 > > Maybe Jack could shed some light on the whether the updates could > somehow work out to be a fix for your problem -- or whether or not > your issue is even related to the em(4) driver. > > -Brandon > From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 02:52:14 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12D9106566B; Sun, 20 Feb 2011 02:52:14 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4DFFD8FC1B; Sun, 20 Feb 2011 02:52:13 +0000 (UTC) Received: by wyb32 with SMTP id 32so790341wyb.13 for ; Sat, 19 Feb 2011 18:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R332/FWu8irzFwewWsezD1xO59NXaxdDG2VfMSE2cqk=; b=GLgQM20k2fdTbthl2B+AGfIP6b6M8rSTBVQrBg/DjACDrTHP+S/ptOynKuZhCysfF2 mvKrf+YEf51Lit+RxaUgClnZ/PJhSvggjddnsqua+fdY+NksquMt1MVYCBNCy4B0VcDq GbJORMxQ+ZU87ZoCEbE5n3Xv8OOm+OKUz5R/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cvqFHeyngiqB6lvdOQpIChi93rHycutNamicqIOiJiRvlBssz9p2bJHdeVQZgGxFBv CCDiMovJT7X04VKA/TUaiz+zXywwHg3MvPYCKvzfEXgWLyO+SuZRF6pcvlj+zWlI1P+B 0nPExMAV5c8fCovvE2uf9llcZDG16DRp+9wlI= MIME-Version: 1.0 Received: by 10.216.19.133 with SMTP id n5mr838430wen.83.1298170332959; Sat, 19 Feb 2011 18:52:12 -0800 (PST) Received: by 10.216.244.130 with HTTP; Sat, 19 Feb 2011 18:52:12 -0800 (PST) In-Reply-To: References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 20:52:12 -0600 Message-ID: From: Brandon Gooch To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Tyll , freebsd-net@freebsd.org, Luigi Rizzo , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 02:52:15 -0000 On Sat, Feb 19, 2011 at 8:40 PM, Jack Vogel wrote: > I've never seen a trace like this, and no absolutely nothing about dummynet, > sorry. > If it is in some way em's fault, then making sure you have the latest code > would be > a good idea. I have a test driver that is under selective test, it does > effect the code > path that you seem to be in, so it might be worth a try. If you want to try > it early > just pipe up and I'll send it. > > Jack I was actually going to suggest Pawl try a different network device if possible. I'm using dummynet on a network gateway equipped with on-board bge(4). I haven't had any crashes, but then again, I'm not seeing that many packets either. -Brandon From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 03:39:08 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1146F106567A for ; Sun, 20 Feb 2011 03:39:08 +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 C1EF38FC12 for ; Sun, 20 Feb 2011 03:39:07 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr08Y-000AJD-JE for freebsd-ipfw@freebsd.org; Sun, 20 Feb 2011 04:39:06 +0100 Date: Sun, 20 Feb 2011 04:38:02 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1385625194.20110220043802@nitronet.pl> To: Brandon Gooch In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 03:39:08 -0000 > Same backtrace as reported here? I'm unable to get the new backtrace, but judging from what I can see on the console pre-reboot, it's exactly the same deal since 8.0-RELEASE - panic with dummynet as main star. > What revision of the em(4) driver code are you using? I know Jack has > been working out certain quirky issues lately, and there have been > updates to the code since last you posted an update to your problem. em0: port 0x2040-0x205f mem 0x= b1a00000-0xb1a1ffff,0xb1a25000-0xb1a25fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:... em1: port 0x1000-0x101f mem 0x= b1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:.. > Maybe Jack could shed some light on the whether the updates could > somehow work out to be a fix for your problem -- or whether or not > your issue is even related to the em(4) driver. I'm not sure anymore that em is at fault here. Anyway, currently I'm running FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28. If something happened since then that could fix this, I'll gladly update. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 03:45:34 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 526D1106564A for ; Sun, 20 Feb 2011 03:45:34 +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 0CA288FC16 for ; Sun, 20 Feb 2011 03:45:33 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr0Em-000AYF-Tr for freebsd-ipfw@freebsd.org; Sun, 20 Feb 2011 04:45:32 +0100 Date: Sun, 20 Feb 2011 04:44:27 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1163871443.20110220044427@nitronet.pl> To: Brandon Gooch In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 03:45:34 -0000 > I was actually going to suggest Pawl try a different network device if > possible. I'm using dummynet on a network gateway equipped with > on-board bge(4). I haven't had any crashes, but then again, I'm not > seeing that many packets either. It seems to be closely related to amount of processed packets. We've connected some new customers recently, which obviously translated to more traffic and more pipes: # Uptime | System Bo= ot up ----------------------------+----------------------------------------------= ----- 1 15 days, 05:42:23 | FreeBSD 8.2-PRERELEASE Wed Dec 22 16:19:55= 2010 2 14 days, 22:31:42 | FreeBSD 8.2-PRERELEASE Sun Jan 9 03:07:59= 2011 3 14 days, 05:25:46 | FreeBSD 8.2-PRERELEASE Mon Jan 24 01:55:34= 2011 4 12 days, 15:42:45 | FreeBSD 8.2-PRERELEASE Mon Feb 7 07:30:07= 2011 In general, our traffic increases, which apparently translates to crashing sooner. When all this started I remember seeing crashes closer to three weeks, but now it surprised me by crashing two days "early". As to trying different device, these are on-board interfaces on Intel mainboard. I don't have any experience with external pci express adapters other than Intel's, could you recommend something stable? From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 03:55:44 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9779A106564A for ; Sun, 20 Feb 2011 03:55:44 +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 5348F8FC08 for ; Sun, 20 Feb 2011 03:55:44 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr0Od-000Au4-7t for freebsd-ipfw@freebsd.org; Sun, 20 Feb 2011 04:55:43 +0100 Date: Sun, 20 Feb 2011 04:54:34 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1145317277.20110220045434@nitronet.pl> To: Jack Vogel In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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, Luigi Rizzo , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 03:55:44 -0000 > I've never seen a trace like this, and no absolutely nothing about dummyn= et, sorry. > If it is in some way em's fault, then making sure you have the latest cod= e would be > a good idea. I have a test driver that is under selective test, it does e= ffect the code > path that you seem to be in, so it might be worth a try. If you want to t= ry it early > just pipe up and I'll send it. I'm less and less sure that it has anything to do with em. I'd like to hear Luigi's take on all this. That being said, I'll gladly try the new driver -- if I'm right, I'll drop under 7 day reboot threshold later into the year anyway, so I really need a permanent solution of some kind. Apparently next crash always comes sooner that previous one, which coincides with growing traffic. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 13:45:28 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B808D106566B for ; Sun, 20 Feb 2011 13:45:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 524A18FC0C for ; Sun, 20 Feb 2011 13:45:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B573B73098; Sun, 20 Feb 2011 14:58:55 +0100 (CET) Date: Sun, 20 Feb 2011 14:58:55 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20110220135855.GA4794@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145317277.20110220045434@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 13:45:28 -0000 On Sun, Feb 20, 2011 at 04:54:34AM +0100, Pawel Tyll wrote: > > I've never seen a trace like this, and no absolutely nothing about dummynet, sorry. > > If it is in some way em's fault, then making sure you have the latest code would be > > a good idea. I have a test driver that is under selective test, it does effect the code > > path that you seem to be in, so it might be worth a try. If you want to try it early > > just pipe up and I'll send it. > I'm less and less sure that it has anything to do with em. I'd like to > hear Luigi's take on all this. That being said, I'll gladly try the > new driver -- if I'm right, I'll drop under 7 day reboot threshold > later into the year anyway, so I really need a permanent solution of > some kind. Apparently next crash always comes sooner that previous > one, which coincides with growing traffic. > i fully welcome pawel's (or everyone else's) bug reports, and consider them as his contribution to improve the system and not as a way to get free consulting, so no need for him to apolgize. In fact, i even welcome direct emails if people feel i missed some reports which i should read. At the same time, everyone should understand that some bugs are hard and time-consuming to track down, and so when the presentation suggests that the problem falls in this category, even developers with deep knowledge of the subsystems involved may step back because of lack of time (and this would not be fixable even if monetary incentives were involved). Conversely, there are cases where somehow one can quickly identify a problem and a fix, and you see it coming out either as a commit to the source tree, or as a patch by email. I have done this myself many times, and have seen the same for many other developers. The way a problem is presented has a big impact on how it gets handled: in this specific case the poster is pointing out a possible culprit (which may be helpful or misleading), and gives no hint on other things that may be relevant: number of interfaces, vlans, tunnels, taps, bpf etc ? any significant other activity on the machine such as interfaces going up or down, routing deamons etc ? amount of traffic ? Without furter details, I can only trust the statements in the report, and this determines how i classify the bug and decide whether i have time or ideas to pursue it. The bug in this case seems to fall in the 'hard, irreproducible' category: panics *always* need many many days to happen on machines under heavy load, no panics on similar machines under lighter load. With a description like this, i am afraid, i can't even start looking at the problem becaue i have no chance to reproduce it. Now let's forget what is in the bug report and dig into the backtrace at http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 assuming that the information there is reliable (which we cannot tell for sure, as the stack could be corrupt). Note that this is some analysis that I would expect the poster to make, because it does not require a huge amount of time and is part of the "fair" sharing of responsibilities to get a bug fixed in a cooperative enviroment. The panic seems to occur in at /usr/src/sys/amd64/amd64/exception.S:223 #7 0xffffffff80698abf in in_localaddr (in=Variable "in" is not available. ) at /usr/src/sys/netinet/in.c:115 which is a piece of code that scans the list of interfaces. The argument to in_localaddr() is an ipv4 addr passed by value, so it is certainly not guilty even if we had a bogus argument. This seems to suggest that the problem is elsewhere -- perhaps some piece of code is manipulating the IN_IFADDR list without locking, causing it to become corrupt ? cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 22:50:49 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 272551065672 for ; Sun, 20 Feb 2011 22:50:49 +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 D626D8FC1A for ; Sun, 20 Feb 2011 22:50:48 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrI75-000DKr-IH for freebsd-ipfw@freebsd.org; Sun, 20 Feb 2011 23:50:47 +0100 Date: Sun, 20 Feb 2011 23:50:28 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <288793167.20110220235028@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220135855.GA4794@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 22:50:49 -0000 > The way a problem is presented has a big impact on how it gets handled: > in this specific case the poster is pointing out a possible culprit > (which may be helpful or misleading), and gives no hint on other > things that may be relevant: number of interfaces, vlans, tunnels, taps, > bpf etc ? any significant other activity on the machine such as interfaces > going up or down, routing deamons etc ? amount of traffic ? > Without furter details, I can only trust the statements in the report, > and this determines how i classify the bug and decide whether i have time > or ideas to pursue it. > The bug in this case seems to fall in the 'hard, irreproducible' category: > panics *always* need many many days to happen on machines under heavy loa= d, > no panics on similar machines under lighter load. > With a description like this, i am afraid, i can't even start looking > at the problem becaue i have no chance to reproduce it. This machine is only doing dummynet traffic shaping from significant things (otherwise it runs a dhcpd, ntpd and named). It's pretty straight-forward routing, packets come in, packets come out via static routes - there are currently no routing daemons involved. As to the interfaces, there are two physical ifaces, em0 and em1, only em1 is currently used. There are 49 vlan interfaces connected to em1, and they are pretty much static, no IP address changes, no interfaces going up or down, sometimes new one is being added, but there is no automation here, and panics do not coincide with anything significant in logs, or being done manually. Traffic oscillates between 20k pps at night and close to 35-40k pps daytime, slightly more on weekends. There are currently 2556 pipes defined and traffic shaping is done with two rules: 30000 pipe tablearg ip from table(100) to any in 30001 pipe tablearg ip from any to table(101) out Currently running FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28 CET 2011, but problem persists since 8.0-RELEASE net.inet.flowtable.enable=3D0 net.inet.ip.fw.one_pass=3D0 net.inet.tcp.blackhole=3D2 net.inet.udp.blackhole=3D1 net.inet.ip.random_id=3D1 net.inet.ip.forwarding=3D1 kern.ipc.maxsockbuf=3D8388608 net.inet.tcp.sendspace=3D4194304 net.inet.tcp.recvspace=3D4194304 net.inet.udp.recvspace=3D1048576 net.inet.udp.maxdgram=3D65536 net.inet.ip.fw.dyn_buckets=3D16384 net.inet.ip.fw.dyn_max=3D65536 hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 4240433152 hw.usermem: 2734768128 Base Board Information Manufacturer: Intel Corporation Product Name: S3420GP em1: port 0x1000-0x101f mem 0x= b1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors If I missed anything here, then just tell me what more I can do, my intentions were never to make this harder to debug or hide anything relevant. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 23:04:56 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4247E106566B; Sun, 20 Feb 2011 23:04:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 00CB58FC15; Sun, 20 Feb 2011 23:04:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CAEB473098; Mon, 21 Feb 2011 00:18:25 +0100 (CET) Date: Mon, 21 Feb 2011 00:18:25 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20110220231825.GA10566@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <288793167.20110220235028@nitronet.pl> User-Agent: Mutt/1.4.2.3i 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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:04:56 -0000 On Sun, Feb 20, 2011 at 11:50:28PM +0100, Pawel Tyll wrote: ... > This machine is only doing dummynet traffic shaping from significant > things (otherwise it runs a dhcpd, ntpd and named). It's pretty > straight-forward routing, packets come in, packets come out via static > routes - there are currently no routing daemons involved. As to the > interfaces, there are two physical ifaces, em0 and em1, only em1 is > currently used. There are 49 vlan interfaces connected to em1, and > they are pretty much static, no IP address changes, no interfaces > going up or down, sometimes new one is being added, but there is no > automation here, and panics do not coincide with anything significant > in logs, or being done manually. Traffic oscillates between 20k pps at > night and close to 35-40k pps daytime, slightly more on weekends. > There are currently 2556 pipes defined and traffic shaping is done > with two rules: > > 30000 pipe tablearg ip from table(100) to any in > 30001 pipe tablearg ip from any to table(101) out > ... > If I missed anything here, then just tell me what more I can do, my > intentions were never to make this harder to debug or hide anything > relevant. understood. I am just saying that for instance the vlan presence and changes is quite significant in this context. You say vlans are "pretty much static" but can you tell us who adds/remove them, assign addresses ? Also the ruleset must have something more than those two rules. >From the stack trace, the panic seems to occur in a call to the "antispoof" option which presumably is somewhere in your ruleset. If not, then the stack is corrupt. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 23:13:39 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 864B2106564A for ; Sun, 20 Feb 2011 23:13:39 +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 40A528FC16 for ; Sun, 20 Feb 2011 23:13:39 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrITC-000F18-CX for freebsd-ipfw@freebsd.org; Mon, 21 Feb 2011 00:13:38 +0100 Date: Mon, 21 Feb 2011 00:13:12 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1167743969.20110221001312@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220231825.GA10566@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> 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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:13:39 -0000 > understood. I am just saying that for instance the vlan presence and > changes is quite significant in this context. > You say vlans are "pretty much static" but can you tell us who adds/remove > them, assign addresses ? It's not that much work and changes are simple and far between. I do that personally. IP addresses don't change, however I sometimes (rarely) destroy and recreate vlans. Panics don't happen immediately after this operation, or while it happens, and there were times from panic to panic that I didn't touch a thing. > Also the ruleset must have something more than those two rules. > From the stack trace, the panic seems to occur in a call to the > "antispoof" option which presumably is somewhere in your ruleset. > If not, then the stack is corrupt. Full ruleset with IP addresses removed: 00010 1691 128516 deny ip from any to any not antispoof in 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) 00050 3246 156244 allow tcp from any to [removed] dst-port 53 = // DNS Rules 50-59 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules= 50-59 00059 23891 1091822 deny ip from any to [removed] // DNS Rules 5= 0-59 00100 32 2176 allow ip from any to any via lo0 00100 929493 48342523 deny ip from any to table(10) dst-port 131-1= 39,445 00102 56574 2779124 fwd [removed] tcp from table(1) to not table= (5) dst-port 80 00103 0 0 fwd [removed] tcp from table(2) to not table= (5) dst-port 80 00104 427 17244 fwd [removed] tcp from table(3) to not table= (5) 00105 6 808 deny ip from table(3) to not table(5) 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6typ= es 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6typ= es 2,135,136 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not = 192.168.0.0/16 65534 1595697378 1254723485778 allow ip from any to any 65535 0 0 allow ip from any to any 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 Should IP addresses be required, I'll gladly send "uncensored" ruleset to you privately. From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 23:42:10 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A200D1065670; Sun, 20 Feb 2011 23:42:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 47E298FC12; Sun, 20 Feb 2011 23:42:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C7FAA73098; Mon, 21 Feb 2011 00:55:40 +0100 (CET) Date: Mon, 21 Feb 2011 00:55:40 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167743969.20110221001312@nitronet.pl> User-Agent: Mutt/1.4.2.3i 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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:42:10 -0000 On Mon, Feb 21, 2011 at 12:13:12AM +0100, Pawel Tyll wrote: > > understood. I am just saying that for instance the vlan presence and > > changes is quite significant in this context. > > You say vlans are "pretty much static" but can you tell us who adds/remove > > them, assign addresses ? > It's not that much work and changes are simple and far between. I do > that personally. IP addresses don't change, however I sometimes > (rarely) destroy and recreate vlans. Panics don't happen immediately > after this operation, or while it happens, and there were times from > panic to panic that I didn't touch a thing. > > > Also the ruleset must have something more than those two rules. > > From the stack trace, the panic seems to occur in a call to the > > "antispoof" option which presumably is somewhere in your ruleset. > > If not, then the stack is corrupt. > Full ruleset with IP addresses removed: > 00010 1691 128516 deny ip from any to any not antispoof in > 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) > 00050 3246 156244 allow tcp from any to [removed] dst-port 53 // DNS Rules 50-59 > 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules 50-59 > 00059 23891 1091822 deny ip from any to [removed] // DNS Rules 50-59 > 00100 32 2176 allow ip from any to any via lo0 > 00100 929493 48342523 deny ip from any to table(10) dst-port 131-139,445 > 00102 56574 2779124 fwd [removed] tcp from table(1) to not table(5) dst-port 80 > 00103 0 0 fwd [removed] tcp from table(2) to not table(5) dst-port 80 > 00104 427 17244 fwd [removed] tcp from table(3) to not table(5) > 00105 6 808 deny ip from table(3) to not table(5) > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 0 0 allow ipv6-icmp from :: to ff02::/16 > 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 > 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in > 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out > 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) > 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not 192.168.0.0/16 > 65534 1595697378 1254723485778 allow ip from any to any > 65535 0 0 allow ip from any to any > > 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 > > Should IP addresses be required, I'll gladly send "uncensored" ruleset > to you privately. 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. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 20 23:51:25 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E20106567A for ; Sun, 20 Feb 2011 23:51:25 +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 4F7118FC16 for ; Sun, 20 Feb 2011 23:51:25 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrJ3k-000Gq3-7n for freebsd-ipfw@freebsd.org; Mon, 21 Feb 2011 00:51:24 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:51:25 -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. From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 21 07:35:50 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA8C3106564A; Mon, 21 Feb 2011 07:35:50 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 25FC48FC14; Mon, 21 Feb 2011 07:35:48 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1L6LRFn012282; Mon, 21 Feb 2011 17:21:27 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1L6LJmQ010223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 17:21:22 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p1L6LETZ083259; Mon, 21 Feb 2011 17:21:15 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p1L6LDAD083258; Mon, 21 Feb 2011 17:21:13 +1100 (EST) (envelope-from peter) Date: Mon, 21 Feb 2011 17:21:13 +1100 From: Peter Jeremy To: Pawel Tyll Message-ID: <20110221062113.GA83219@server.vk2pj.dyndns.org> References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <410175608.20110220013900@nitronet.pl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 07:35:50 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote: >Since nobody came up with any interest in having this properly >investigated, then I suppose I'm the only one that uses dummynet for >some larger-scale traffic shaping - maybe that's my mistake? I'm using dummpnet+pf (not ipfw) on (roughly) FreeBSD 7.2 quite extensively for traffic shaping. I have about 20 pipes varying from 600kbps to 100Mbps all with ~9msec delay. There's a background load of at least 10Mbps with peaks to several times that (and several 2Mbps pipes are virtually permanently saturated). The system has nearly 80 VLANs and uses CARP and lagg/LACP (1 bge and 1 em NIC) for redundancy. The system has an uptime of several months. I haven't responded before because I can't offer any solutions. All I can say is that I've been successfully using dummynet with ipfw or pf for about a decade without any stability issues. --=20 Peter Jeremy --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1iBFkACgkQ/opHv/APuIe8FgCgwLaCw6x/lVQE+huwihvGlcpb ED8AoLV9lXQhR69nr5EWgqilDfiAjokm =3fE5 -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 21 11:07:01 2011 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF3D1065700 for ; Mon, 21 Feb 2011 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C2DC58FC16 for ; Mon, 21 Feb 2011 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1LB71db075734 for ; Mon, 21 Feb 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1LB71tE075732 for freebsd-ipfw@FreeBSD.org; Mon, 21 Feb 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Feb 2011 11:07:01 GMT Message-Id: <201102211107.p1LB71tE075732@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 11:07:02 -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/153415 ipfw [ipfw] [patch] Port numbers always zero in dynamic IPF o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o kern/122109 ipfw [ipfw] ipfw nat traceroute problem s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet] 6.3-RELEASE-p1 page fault in dummynet (corr o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 78 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 21 13:25:15 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97DC106566B; Mon, 21 Feb 2011 13:25:15 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7238FC16; Mon, 21 Feb 2011 13:25:14 +0000 (UTC) Received: from f119.mail.ru (f119.mail.ru [217.69.129.112]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id 61E495A7721A; Mon, 21 Feb 2011 16:08:30 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=OgcrlTn/vkFWFLekYw2Jl3iX+dWFbR4YhhzGOVgrVmE=; b=GxN7l1sxZRnHjk+9/Rldz4dfrAums1h97J2659gooKLciKraDPPlXHxZds39kN5VSLs/jCnPdTzlfTDLeyEFlKjebm2cBKVcujrmr7LkwhSBLN/tfYNZDTWdIiOrT9mw; Received: from mail by f119.mail.ru with local id 1PrVUT-0006Fh-00; Mon, 21 Feb 2011 16:07:49 +0300 Received: from [77.45.152.48] by e.mail.ru with HTTP; Mon, 21 Feb 2011 16:07:49 +0300 From: Andrey Smagin To: Pawel Tyll Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.152.48] Date: Mon, 21 Feb 2011 16:07:49 +0300 References: <20110220231825.GA10566@onelab2.iet.unipi.it> <410175608.20110220013900@nitronet.pl> <1167743969.20110221001312@nitronet.pl> In-Reply-To: <1167743969.20110221001312@nitronet.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re[2]: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:25:15 -0000 I think problem may be like there http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025156.html what type of IFace for your FWD rules ? I have crash only for ng IF. over gif fwd work without problem. But it only for my case. Mon, 21 Feb 2011 00:13:12 +0100 письмо от Pawel Tyll : > > understood. I am just saying that for instance the vlan presence and > > changes is quite significant in this context. > > You say vlans are "pretty much static" but can you tell us who adds/remove > > them, assign addresses ? > It's not that much work and changes are simple and far between. I do > that personally. IP addresses don't change, however I sometimes > (rarely) destroy and recreate vlans. Panics don't happen immediately > after this operation, or while it happens, and there were times from > panic to panic that I didn't touch a thing. > > > Also the ruleset must have something more than those two rules. > > From the stack trace, the panic seems to occur in a call to the > > "antispoof" option which presumably is somewhere in your ruleset. > > If not, then the stack is corrupt. > Full ruleset with IP addresses removed: > 00010 1691 128516 deny ip from any to any not antispoof in > 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) > 00050 3246 156244 allow tcp from any to [removed] dst-port 53 // > DNS Rules 50-59 > 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules > 50-59 > 00059 23891 1091822 deny ip from any to [removed] // DNS Rules > 50-59 > 00100 32 2176 allow ip from any to any via lo0 > 00100 929493 48342523 deny ip from any to table(10) dst-port > 131-139,445 > 00102 56574 2779124 fwd [removed] tcp from table(1) to not table(5) > dst-port 80 > 00103 0 0 fwd [removed] tcp from table(2) to not table(5) > dst-port 80 > 00104 427 17244 fwd [removed] tcp from table(3) to not table(5) > 00105 6 808 deny ip from table(3) to not table(5) > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 0 0 allow ipv6-icmp from :: to ff02::/16 > 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 1 > 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 2,135,136 > 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in > 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out > 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) > 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not > 192.168.0.0/16 > 65534 1595697378 1254723485778 allow ip from any to any > 65535 0 0 allow ip from any to any > > 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 > > Should IP addresses be required, I'll gladly send "uncensored" ruleset > to you privately. > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 23 15:52:23 2011 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39ACE106564A for ; Wed, 23 Feb 2011 15:52:23 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 692968FC16 for ; Wed, 23 Feb 2011 15:52:22 +0000 (UTC) Received: (qmail 68889 invoked from network); 23 Feb 2011 12:25:40 -0300 Received: by simscan 1.4.0 ppid: 68884, pid: 68887, t: 0.0032s scanners:none Received: from unknown (HELO eksffa-mac.bh.freebsdbrasil.com.br) (eksffa@freebsdbrasil.com.br@201.48.151.226) by capeta.freebsdbrasil.com.br with ESMTPA; 23 Feb 2011 12:25:40 -0300 From: Patrick Tracanelli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2011 12:25:39 -0300 Message-Id: <8B6C1E5B-F1EA-46DC-816B-27F204449C32@freebsdbrasil.com.br> To: ipfw@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: Subject: Excessive "intr" CPU usage caused by Dummynet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:52:23 -0000 Hello Gentlemen, What may cause dummynet to exaust CPU cycles on kernel "intr" requests? I am facing a situation where "top -S" shows something like that: 12 root 13 -60 - 0K 104K WAIT 0 744:58 82.50% intr And when I get into >95% intr cpu usage, packets on dummynet raise their = latency a lot, slowing down everything (pipe or queue). Queue sizes are ajusted according to pipe bandwidth, using a sort of = rule where queue in bytes is equal to pipe width divided by 8 or by 10. Thank you. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 25 15:48:27 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F29E106566B for ; Fri, 25 Feb 2011 15:48:27 +0000 (UTC) (envelope-from michael.scheidell@secnap.com) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [204.89.241.253]) by mx1.freebsd.org (Postfix) with ESMTP id 698EC8FC0A for ; Fri, 25 Feb 2011 15:48:27 +0000 (UTC) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [10.70.1.253]) by mx1.secnap.com.ionspam.net (Postfix) with ESMTP id B01822B7C5C for ; Fri, 25 Feb 2011 10:28:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secnap.com; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:from:from:date:date:message-id; s=dkim; t=1298647708; x=1300462108; bh=qlgmYCX4Dlc9nKQhYMurN9Nt 2ioQjyloelarBQtI1Sw=; b=CB6W1Bf+jch0rcs2//kvyW91FurYl+O6yjCsVEX6 FLnG/0iOUHnZsv3uOEXQWXwYzl7Q4/RfFNhyzJmLWHcH1Xaxb3Irc8p/xQnfm5k1 QfG2IKkD2hVtca+t8xmKdboa/VsXH6sZKmQMtIBbY8mGquwrexdhmRGawcp/FgAU KO0= X-Amavis-Modified: Mail body modified (using disclaimer) - mx1.secnap.com.ionspam.net X-Virus-Scanned: SpammerTrap(r) VPS-1500 2.14 at mx1.secnap.com.ionspam.net Received: from USBCTDC001.secnap.com (usbctdc001.secnap.com [10.70.1.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.secnap.com.ionspam.net (Postfix) with ESMTPS id 7E1CA2B7C0B for ; Fri, 25 Feb 2011 10:28:28 -0500 (EST) Received: from macintosh.secnap.com (10.70.3.3) by USBCTDC001.secnap.com (10.70.1.1) with Microsoft SMTP Server (TLS) id 14.0.722.0; Fri, 25 Feb 2011 10:28:28 -0500 Message-ID: <4D67CAB0.7090700@secnap.com> Date: Fri, 25 Feb 2011 10:28:48 -0500 From: Michael Scheidell User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: looking to translate SRC port as well. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:48:27 -0000 In short, I have a sip server that is very restrictive on the dst port, and a sip trunk provider that is very restrictive on src ports. Naturally, its a great sip server, and a great sip trunk service, and the ports each one demands are not the same. the sip server listens on udp port 5080, and the sip trunk provider MUST send TO udp port 5060. (easy, right?) no, when the sip server sends to the sip trunk provider, the sip trunk provider must think the sip server src port is 5060 also! (and it is not) So, the sip server must think it is sending and receiving sip on port 5080, the sip trunk must think it is sending and receiving on port 5060. I have looked at ipfw/divert sockets, netawk, natd, and trying to find the easiest way to do it. I thought about writing a perl module, and have ipfw divert to it (perl has optional divert socket pm's) traffic map should look like this inbound: em0: siptrunk.sipprovider.com:5060 -> em1: sipswitch.secnap.com:5060 (leg before translation) after translation: em0: siptrunk.sipprovider.com:5080 -> em1: sipswitch.secnap.com:5080. outbound: em1:sipswitch.secnap.com:5080 -> em0: siptrunk.sipprovider.com:5080 (leg before translation) em1: sipwwitch.secnap.com:5060 -> em0: siptrunk.sipprovider.com:5060 (leg after translation) see, its not just the dst port I need translated, but the src port that the other side sees as well. additional notes: I can capture inbound and outbound via if_bridge, since em0 and em1 are using a transparent ipfw->if_bridge fw. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 >*| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 ______________________________________________________________________ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ ______________________________________________________________________ From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 25 17:40:03 2011 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F2D1065694 for ; Fri, 25 Feb 2011 17:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDAC8FC15 for ; Fri, 25 Feb 2011 17:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1PHe3Q1025043 for ; Fri, 25 Feb 2011 17:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1PHe3Ca025042; Fri, 25 Feb 2011 17:40:03 GMT (envelope-from gnats) Date: Fri, 25 Feb 2011 17:40:03 GMT Message-Id: <201102251740.p1PHe3Ca025042@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Sergey Matveychuk Cc: Subject: Re: kern/128260: [ipfw] [patch] ipfw_divert damages IPv6 packets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Matveychuk List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:40:03 -0000 The following reply was made to PR kern/128260; it has been noted by GNATS. From: Sergey Matveychuk To: bug-followup@FreeBSD.org, dan@obluda.cz Cc: Julian Elischer Subject: Re: kern/128260: [ipfw] [patch] ipfw_divert damages IPv6 packets Date: Fri, 25 Feb 2011 20:14:50 +0300 This is a multi-part message in MIME format. --------------080106090909020900000003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Here is my patch for IPv6 divert. It works for me, but it should be reviewed and may be improved. I've touched nd6.c to prevent looping packet to local address (loopback). Any questions are welcome. --------------080106090909020900000003 Content-Type: text/plain; name="divert-ipv6.diff.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="divert-ipv6.diff.txt" LS0tIHN5cy9uZXRpbmV0L2lwZncvaXBfZndfcGZpbC5jLm9yaWcJMjAxMS0wMi0yNSAxNzo0 OToxNS4wMDAwMDAwMDAgKzAzMDAKKysrIHN5cy9uZXRpbmV0L2lwZncvaXBfZndfcGZpbC5j CTIwMTEtMDItMjUgMTc6NDk6MjcuMDAwMDAwMDAwICswMzAwCkBAIC0yODksNyArMjg5LDcg QEAKIAkgKiB3ZSBjYW4gZG8gaXQgYmVmb3JlIGEgJ3RlZScuCiAJICovCiAJaXAgPSBtdG9k KGNsb25lLCBzdHJ1Y3QgaXAgKik7Ci0JaWYgKCF0ZWUgJiYgbnRvaHMoaXAtPmlwX29mZikg JiAoSVBfTUYgfCBJUF9PRkZNQVNLKSkgeworCWlmIChpcC0+aXBfdiA9PSA0ICYmICF0ZWUg JiYgbnRvaHMoaXAtPmlwX29mZikgJiAoSVBfTUYgfCBJUF9PRkZNQVNLKSkgewogCQlpbnQg aGxlbjsKIAkJc3RydWN0IG1idWYgKnJlYXNzOwogCi0tLSBzeXMvbmV0aW5ldC9pcF9kaXZl cnQuYy5vcmlnCTIwMTEtMDItMjUgMTc6NDk6MDQuMDAwMDAwMDAwICswMzAwCisrKyBzeXMv bmV0aW5ldC9pcF9kaXZlcnQuYwkyMDExLTAyLTI1IDE3OjQ5OjM2LjAwMDAwMDAwMCArMDMw MApAQCAtNjksNiArNjksOCBAQAogI2luY2x1ZGUgPG5ldGluZXQvaW5fdmFyLmg+CiAjaW5j bHVkZSA8bmV0aW5ldC9pcC5oPgogI2luY2x1ZGUgPG5ldGluZXQvaXBfdmFyLmg+CisjaW5j bHVkZSA8bmV0aW5ldC9pcDYuaD4KKyNpbmNsdWRlIDxuZXRpbmV0Ni9pcDZfdmFyLmg+CiAj aWZkZWYgU0NUUAogI2luY2x1ZGUgPG5ldGluZXQvc2N0cF9jcmMzMi5oPgogI2VuZGlmCkBA IC0zODksNzEgKzM5MSw3OCBAQAogCS8qIFJlaW5qZWN0IHBhY2tldCBpbnRvIHRoZSBzeXN0 ZW0gYXMgaW5jb21pbmcgb3Igb3V0Z29pbmcgKi8KIAlpZiAoIXNpbiB8fCBzaW4tPnNpbl9h ZGRyLnNfYWRkciA9PSAwKSB7CiAJCXN0cnVjdCBpcCAqY29uc3QgaXAgPSBtdG9kKG0sIHN0 cnVjdCBpcCAqKTsKKyNpZmRlZiBJTkVUNgorCQlzdHJ1Y3QgaXA2X2hkciAqY29uc3QgaXA2 ID0gbXRvZChtLCBzdHJ1Y3QgaXA2X2hkciAqKTsKKyNlbmRpZgogCQlzdHJ1Y3QgaW5wY2Ig KmlucDsKIAogCQlkdC0+aW5mbyB8PSBJUEZXX0lTX0RJVkVSVCB8IElQRldfSU5GT19PVVQ7 CiAJCWlucCA9IHNvdG9pbnBjYihzbyk7CiAJCUlOUF9STE9DSyhpbnApOwotCQkvKgotCQkg KiBEb24ndCBhbGxvdyBib3RoIHVzZXIgc3BlY2lmaWVkIGFuZCBzZXRzb2Nrb3B0IG9wdGlv bnMsCi0JCSAqIGFuZCBkb24ndCBhbGxvdyBwYWNrZXQgbGVuZ3RoIHNpemVzIHRoYXQgd2ls bCBjcmFzaAotCQkgKi8KLQkJaWYgKCgoaXAtPmlwX2hsICE9IChzaXplb2YgKCppcCkgPj4g MikpICYmIGlucC0+aW5wX29wdGlvbnMpIHx8Ci0JCSAgICAgKCh1X3Nob3J0KW50b2hzKGlw LT5pcF9sZW4pID4gbS0+bV9wa3RoZHIubGVuKSkgewotCQkJZXJyb3IgPSBFSU5WQUw7Ci0J CQlJTlBfUlVOTE9DSyhpbnApOwotCQkJbV9mcmVlbShtKTsKLQkJfSBlbHNlIHsKKworCQlp ZihpcC0+aXBfdiA9PSA0KSB7CiAJCQkvKiBDb252ZXJ0IGZpZWxkcyB0byBob3N0IG9yZGVy IGZvciBpcF9vdXRwdXQoKSAqLwogCQkJaXAtPmlwX2xlbiA9IG50b2hzKGlwLT5pcF9sZW4p OwogCQkJaXAtPmlwX29mZiA9IG50b2hzKGlwLT5pcF9vZmYpOworCQl9CisjaWZkZWYgSU5F VDYJCQorCQllbHNlCisJCQlpcDYtPmlwNl9wbGVuID0gbnRvaHMoaXA2LT5pcDZfcGxlbik7 CisjZW5kaWYKIAotCQkJLyogU2VuZCBwYWNrZXQgdG8gb3V0cHV0IHByb2Nlc3NpbmcgKi8K LQkJCUtNT0RfSVBTVEFUX0lOQyhpcHNfcmF3b3V0KTsJCS8qIFhYWCAqLworCQkvKiBTZW5k IHBhY2tldCB0byBvdXRwdXQgcHJvY2Vzc2luZyAqLworCQlLTU9EX0lQU1RBVF9JTkMoaXBz X3Jhd291dCk7CQkvKiBYWFggKi8KIAogI2lmZGVmIE1BQwotCQkJbWFjX2lucGNiX2NyZWF0 ZV9tYnVmKGlucCwgbSk7CisJCW1hY19pbnBjYl9jcmVhdGVfbWJ1ZihpbnAsIG0pOwogI2Vu ZGlmCi0JCQkvKgotCQkJICogR2V0IHJlYWR5IHRvIGluamVjdCB0aGUgcGFja2V0IGludG8g aXBfb3V0cHV0KCkuCi0JCQkgKiBKdXN0IGluIGNhc2Ugc29ja2V0IG9wdGlvbnMgd2VyZSBz cGVjaWZpZWQgb24gdGhlCi0JCQkgKiBkaXZlcnQgc29ja2V0LCB3ZSBkdXBsaWNhdGUgdGhl bS4gIFRoaXMgaXMgZG9uZQotCQkJICogdG8gYXZvaWQgaGF2aW5nIHRvIGhvbGQgdGhlIFBD QiBsb2NrcyBvdmVyIHRoZSBjYWxsCi0JCQkgKiB0byBpcF9vdXRwdXQoKSwgYXMgZG9pbmcg dGhpcyByZXN1bHRzIGluIGEgbnVtYmVyIG9mCi0JCQkgKiBsb2NrIG9yZGVyaW5nIGNvbXBs ZXhpdGllcy4KLQkJCSAqCi0JCQkgKiBOb3RlIHRoYXQgd2Ugc2V0IHRoZSBtdWx0aWNhc3Qg b3B0aW9ucyBhcmd1bWVudCBmb3IKLQkJCSAqIGlwX291dHB1dCgpIHRvIE5VTEwgc2luY2Ug aXQgc2hvdWxkIGJlIGludmFyaWFudCB0aGF0Ci0JCQkgKiB0aGV5IGFyZSBub3QgcHJlc2Vu dC4KLQkJCSAqLwotCQkJS0FTU0VSVChpbnAtPmlucF9tb3B0aW9ucyA9PSBOVUxMLAotCQkJ ICAgICgibXVsdGljYXN0IG9wdGlvbnMgc2V0IG9uIGEgZGl2ZXJ0IHNvY2tldCIpKTsKLQkJ CW9wdGlvbnMgPSBOVUxMOwotCQkJLyoKLQkJCSAqIFhYWENTSlA6IEl0IGlzIHVuY2xlYXIg dG8gbWUgd2hldGhlciBvciBub3QgaXQgbWFrZXMKLQkJCSAqIHNlbnNlIGZvciBkaXZlcnQg c29ja2V0cyB0byBoYXZlIG9wdGlvbnMuICBIb3dldmVyLAotCQkJICogZm9yIG5vdyB3ZSB3 aWxsIGR1cGxpY2F0ZSB0aGVtIHdpdGggdGhlIElOUCBsb2NrcwotCQkJICogaGVsZCBzbyB3 ZSBjYW4gdXNlIHRoZW0gaW4gaXBfb3V0cHV0KCkgd2l0aG91dAotCQkJICogcmVxdXJpbmcg YSByZWZlcmVuY2UgdG8gdGhlIHBjYi4KLQkJCSAqLwotCQkJaWYgKGlucC0+aW5wX29wdGlv bnMgIT0gTlVMTCkgewotCQkJCW9wdGlvbnMgPSBtX2R1cChpbnAtPmlucF9vcHRpb25zLCBN X0RPTlRXQUlUKTsKLQkJCQlpZiAob3B0aW9ucyA9PSBOVUxMKQotCQkJCQllcnJvciA9IEVO T0JVRlM7Ci0JCQl9Ci0JCQlJTlBfUlVOTE9DSyhpbnApOwotCQkJaWYgKGVycm9yID09IEVO T0JVRlMpIHsKLQkJCQltX2ZyZWVtKG0pOwotCQkJCXJldHVybiAoZXJyb3IpOwotCQkJfQot CQkJZXJyb3IgPSBpcF9vdXRwdXQobSwgb3B0aW9ucywgTlVMTCwKLQkJCSAgICAoKHNvLT5z b19vcHRpb25zICYgU09fRE9OVFJPVVRFKSA/Ci0JCQkgICAgSVBfUk9VVEVUT0lGIDogMCkg fCBJUF9BTExPV0JST0FEQ0FTVCB8Ci0JCQkgICAgSVBfUkFXT1VUUFVULCBOVUxMLCBOVUxM KTsKLQkJCWlmIChvcHRpb25zICE9IE5VTEwpCi0JCQkJbV9mcmVlbShvcHRpb25zKTsKKwkJ LyoKKwkJICogR2V0IHJlYWR5IHRvIGluamVjdCB0aGUgcGFja2V0IGludG8gaXBfb3V0cHV0 KCkuCisJCSAqIEp1c3QgaW4gY2FzZSBzb2NrZXQgb3B0aW9ucyB3ZXJlIHNwZWNpZmllZCBv biB0aGUKKwkJICogZGl2ZXJ0IHNvY2tldCwgd2UgZHVwbGljYXRlIHRoZW0uICBUaGlzIGlz IGRvbmUKKwkJICogdG8gYXZvaWQgaGF2aW5nIHRvIGhvbGQgdGhlIFBDQiBsb2NrcyBvdmVy IHRoZSBjYWxsCisJCSAqIHRvIGlwX291dHB1dCgpLCBhcyBkb2luZyB0aGlzIHJlc3VsdHMg aW4gYSBudW1iZXIgb2YKKwkJICogbG9jayBvcmRlcmluZyBjb21wbGV4aXRpZXMuCisJCSAq CisJCSAqIE5vdGUgdGhhdCB3ZSBzZXQgdGhlIG11bHRpY2FzdCBvcHRpb25zIGFyZ3VtZW50 IGZvcgorCQkgKiBpcF9vdXRwdXQoKSB0byBOVUxMIHNpbmNlIGl0IHNob3VsZCBiZSBpbnZh cmlhbnQgdGhhdAorCQkgKiB0aGV5IGFyZSBub3QgcHJlc2VudC4KKwkJICovCisJCUtBU1NF UlQoaW5wLT5pbnBfbW9wdGlvbnMgPT0gTlVMTCwKKwkJICAgICgibXVsdGljYXN0IG9wdGlv bnMgc2V0IG9uIGEgZGl2ZXJ0IHNvY2tldCIpKTsKKwkJb3B0aW9ucyA9IE5VTEw7CisJCS8q CisJCSAqIFhYWENTSlA6IEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hldGhlciBvciBub3QgaXQg bWFrZXMKKwkJICogc2Vuc2UgZm9yIGRpdmVydCBzb2NrZXRzIHRvIGhhdmUgb3B0aW9ucy4g IEhvd2V2ZXIsCisJCSAqIGZvciBub3cgd2Ugd2lsbCBkdXBsaWNhdGUgdGhlbSB3aXRoIHRo ZSBJTlAgbG9ja3MKKwkJICogaGVsZCBzbyB3ZSBjYW4gdXNlIHRoZW0gaW4gaXBfb3V0cHV0 KCkgd2l0aG91dAorCQkgKiByZXF1cmluZyBhIHJlZmVyZW5jZSB0byB0aGUgcGNiLgorCQkg Ki8KKwkJaWYgKGlucC0+aW5wX29wdGlvbnMgIT0gTlVMTCkgeworCQkJb3B0aW9ucyA9IG1f ZHVwKGlucC0+aW5wX29wdGlvbnMsIE1fRE9OVFdBSVQpOworCQkJaWYgKG9wdGlvbnMgPT0g TlVMTCkKKwkJCQllcnJvciA9IEVOT0JVRlM7CiAJCX0KKwkJSU5QX1JVTkxPQ0soaW5wKTsK KwkJaWYgKGVycm9yID09IEVOT0JVRlMpIHsKKwkJCW1fZnJlZW0obSk7CisJCQlyZXR1cm4g KGVycm9yKTsKKwkJfQorCQlpZihpcC0+aXBfdiA9PSA0KQorCQkgICAgZXJyb3IgPSBpcF9v dXRwdXQobSwgb3B0aW9ucywgTlVMTCwKKwkJCSgoc28tPnNvX29wdGlvbnMgJiBTT19ET05U Uk9VVEUpID8KKwkJCUlQX1JPVVRFVE9JRiA6IDApIHwgSVBfQUxMT1dCUk9BRENBU1QgfAor CQkJSVBfUkFXT1VUUFVULCBOVUxMLCBOVUxMKTsKKyNpZmRlZiBJTkVUNgorCQllbHNlCisJ CSAgICBlcnJvciA9IGlwNl9vdXRwdXQobSwgTlVMTCwgTlVMTCwgMCwgCisJCQlOVUxMLCBO VUxMLCBOVUxMKTsKKyNlbmRpZgorCQlpZiAob3B0aW9ucyAhPSBOVUxMKQorCQkJbV9mcmVl bShvcHRpb25zKTsKIAl9IGVsc2UgeworCQlzdHJ1Y3QgaXAgKmNvbnN0IGlwID0gbXRvZCht LCBzdHJ1Y3QgaXAgKik7CisKIAkJZHQtPmluZm8gfD0gSVBGV19JU19ESVZFUlQgfCBJUEZX X0lORk9fSU47CiAJCWlmIChtLT5tX3BrdGhkci5yY3ZpZiA9PSBOVUxMKSB7CiAJCQkvKgpA QCAtNDc3LDcgKzQ4NiwxMiBAQAogCQltYWNfc29ja2V0X2NyZWF0ZV9tYnVmKHNvLCBtKTsK ICNlbmRpZgogCQkvKiBTZW5kIHBhY2tldCB0byBpbnB1dCBwcm9jZXNzaW5nIHZpYSBuZXRp c3IgKi8KLQkJbmV0aXNyX3F1ZXVlX3NyYyhORVRJU1JfSVAsICh1aW50cHRyX3Qpc28sIG0p OworCQlpZihpcC0+aXBfdiA9PSA0KQorCQkgICAgbmV0aXNyX3F1ZXVlX3NyYyhORVRJU1Jf SVAsICh1aW50cHRyX3Qpc28sIG0pOworI2lmZGVmIElORVQ2CisJCWVsc2UKKwkJICAgIG5l dGlzcl9xdWV1ZV9zcmMoTkVUSVNSX0lQVjYsICh1aW50cHRyX3Qpc28sIG0pOworI2VuZGlm CiAJfQogCiAJcmV0dXJuIGVycm9yOwotLS0gc3lzL25ldGluZXQ2L25kNi5jLm9yaWcJMjAx MS0wMi0yNSAxNzo0ODo1NC4wMDAwMDAwMDAgKzAzMDAKKysrIHN5cy9uZXRpbmV0Ni9uZDYu YwkyMDExLTAyLTI1IDE3OjQ5OjUxLjAwMDAwMDAwMCArMDMwMApAQCAtMTkyOCwxMCArMTky OCw2IEBACiAJCX0KIAkJcmV0dXJuIChlcnJvcik7CiAJfQotCWlmICgoaWZwLT5pZl9mbGFn cyAmIElGRl9MT09QQkFDSykgIT0gMCkgewotCQlyZXR1cm4gKCgqaWZwLT5pZl9vdXRwdXQp KG9yaWdpZnAsIG0sIChzdHJ1Y3Qgc29ja2FkZHIgKilkc3QsCi0JCSAgICBOVUxMKSk7Ci0J fQogCWVycm9yID0gKCppZnAtPmlmX291dHB1dCkoaWZwLCBtLCAoc3RydWN0IHNvY2thZGRy ICopZHN0LCBOVUxMKTsKIAlyZXR1cm4gKGVycm9yKTsKIAo= --------------080106090909020900000003-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 25 18:00:24 2011 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A01106566C for ; Fri, 25 Feb 2011 18:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 296588FC0A for ; Fri, 25 Feb 2011 18:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1PI0N72045017 for ; Fri, 25 Feb 2011 18:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1PI0NlA044992; Fri, 25 Feb 2011 18:00:23 GMT (envelope-from gnats) Date: Fri, 25 Feb 2011 18:00:23 GMT Message-Id: <201102251800.p1PI0NlA044992@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Sergey Matveychuk Cc: Subject: Re: kern/128260: [ipfw] [patch] ipfw_divert damages IPv6 packets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Matveychuk List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 18:00:24 -0000 The following reply was made to PR kern/128260; it has been noted by GNATS. From: Sergey Matveychuk To: bug-followup@FreeBSD.org, dan@obluda.cz Cc: Julian Elischer Subject: Re: kern/128260: [ipfw] [patch] ipfw_divert damages IPv6 packets Date: Fri, 25 Feb 2011 20:53:54 +0300 I've forget to mention, it tested only on 8.2. No -CURRENT around, sorry. From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 25 19:51:56 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FA46106567A for ; Fri, 25 Feb 2011 19:51:56 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from mgw1.apollo.lv (mgw1.apollo.lv [80.232.168.216]) by mx1.freebsd.org (Postfix) with ESMTP id E5EEB8FC13 for ; Fri, 25 Feb 2011 19:51:55 +0000 (UTC) Received: from [46.109.210.164] (unknown [46.109.210.164]) by mgw1.apollo.lv (Postfix) with ESMTP id A481B3D6CB8; Fri, 25 Feb 2011 21:35:44 +0200 (EET) From: Dmitriy Demidov To: michael.scheidell@secnap.com, freebsd-ipfw@freebsd.org Date: Fri, 25 Feb 2011 19:35:43 +0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102251935.43414.dima_bsd@inbox.lv> X-Brightmail-Tracker: AAAAAA== Cc: Subject: Re: looking to translate SRC port as well. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:51:56 -0000 > In short, I have a sip server that is very restrictive on the dst port, > and a sip trunk provider that is very restrictive on src ports. > Naturally, its a great sip server, and a great sip trunk service, and > the ports each one demands are not the same. > the sip server listens on udp port 5080, and the sip trunk provider MUST > send TO udp port 5060. > (easy, right?) no, when the sip server sends to the sip trunk provider, > the sip trunk provider must think the sip server src port is 5060 also! > (and it is not) > So, the sip server must think it is sending and receiving sip on port > 5080, the sip trunk must think it is sending and receiving on port 5060. > I have looked at ipfw/divert sockets, netawk, natd, and trying to find > the easiest way to do it. > I thought about writing a perl module, and have ipfw divert to it (perl > has optional divert socket pm's) Hi, you can try to use Netgraph and ng_path node to alter src/dst UDP port number in outgoing/incoming packets flow. This node allows you change just *anything* in the packet. Take a look at man page for ng_path: www.freebsd.org/cgi/man.cgi?query=ng_patch&apropos=0&sektion=0&manpath=FreeBSD+8.1-stable&format=html Good luck.