From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 06:22:47 2009 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 EADA1106566C for ; Sun, 15 Mar 2009 06:22:47 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5445D8FC0A for ; Sun, 15 Mar 2009 06:22:47 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.13.1/8.13.1) with ESMTP id n2F61gCB086513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Mar 2009 13:01:42 +0700 (ICT) (envelope-from on@banyan.cs.ait.ac.th) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.14.2/8.12.11) id n2F653Uw021328; Sun, 15 Mar 2009 13:05:03 +0700 (ICT) Date: Sun, 15 Mar 2009 13:05:03 +0700 (ICT) Message-Id: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-ipfw@freebsd.org X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: ipfw amd bridge 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, 15 Mar 2009 06:22:48 -0000 Hi, I remember reqading in the past (4.x) that on a machine with bridged interfaces, only layer 2 rules of ipfw would apply. Is this still the case with 6.4, 7.1? best regards, Olivier From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 06:46:14 2009 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 19397106564A for ; Sun, 15 Mar 2009 06:46:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0174E8FC0A for ; Sun, 15 Mar 2009 06:46:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 686587C253; Sat, 14 Mar 2009 23:35:20 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 0E0592D601D; Sat, 14 Mar 2009 23:35:19 -0700 (PDT) Message-ID: <49BCA1AC.7080905@elischer.org> Date: Sat, 14 Mar 2009 23:35:24 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Olivier Nicole References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> In-Reply-To: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw amd bridge 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, 15 Mar 2009 06:46:14 -0000 Olivier Nicole wrote: > Hi, > > I remember reqading in the past (4.x) that on a machine with bridged > interfaces, only layer 2 rules of ipfw would apply. not quite. there are rules that do not work when called from a layer two point. e.g. divert does not work, nor does 'fwd' (without patches). Rules not specifically labeled "layer2" will still process packets, but rules labeled "not layer2" will not do so. (as expected). note if_bridge and bridge are different and may have behavioral differences in this regard. > > Is this still the case with 6.4, 7.1? > > best regards, > > Olivier > _______________________________________________ > 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 Sun Mar 15 07:36:54 2009 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 AD3371065678 for ; Sun, 15 Mar 2009 07:36:54 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBF78FC18 for ; Sun, 15 Mar 2009 07:36:53 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.13.1/8.13.1) with ESMTP id n2F7XKed089703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 14:33:20 +0700 (ICT) (envelope-from on@banyan.cs.ait.ac.th) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.14.2/8.12.11) id n2F7acad033835; Sun, 15 Mar 2009 14:36:38 +0700 (ICT) Date: Sun, 15 Mar 2009 14:36:38 +0700 (ICT) Message-Id: <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> From: Olivier Nicole To: julian@elischer.org In-reply-to: <49BCA1AC.7080905@elischer.org> (message from Julian Elischer on Sat, 14 Mar 2009 23:35:24 -0700) References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> <49BCA1AC.7080905@elischer.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw amd bridge 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, 15 Mar 2009 07:36:55 -0000 Thanks, > > I remember reqading in the past (4.x) that on a machine with bridged > > interfaces, only layer 2 rules of ipfw would apply. > > not quite. > there are rules that do not work when called from a layer two > point. e.g. divert does not work, nor does 'fwd' (without patches). And what would be the patches (if any exists)? > note if_bridge and bridge are different and may have > behavioral differences in this regard. I think it will be if_bridge (as bridge is obsolete). Bests, Olivier From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 08:07:53 2009 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 7DD1A1065676 for ; Sun, 15 Mar 2009 08:07:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 638E08FC0C for ; Sun, 15 Mar 2009 08:07:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 5EAB28135E; Sun, 15 Mar 2009 01:07:53 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D44A12D6011; Sun, 15 Mar 2009 01:07:52 -0700 (PDT) Message-ID: <49BCB75D.60408@elischer.org> Date: Sun, 15 Mar 2009 01:07:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Olivier Nicole References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> <49BCA1AC.7080905@elischer.org> <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> In-Reply-To: <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Adrian Chadd Subject: Re: ipfw amd bridge 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, 15 Mar 2009 08:07:53 -0000 Olivier Nicole wrote: > Thanks, > >>> I remember reqading in the past (4.x) that on a machine with bridged >>> interfaces, only layer 2 rules of ipfw would apply. >> not quite. >> there are rules that do not work when called from a layer two >> point. e.g. divert does not work, nor does 'fwd' (without patches). > > And what would be the patches (if any exists)? > >> note if_bridge and bridge are different and may have >> behavioral differences in this regard. > > I think it will be if_bridge (as bridge is obsolete). > > Bests, > > Olivier > > I gave some to adrian (cc'd).. I don't have them available right now.. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 09:38:43 2009 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 6E67C106566C for ; Sun, 15 Mar 2009 09:38:43 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7CA8FC0C for ; Sun, 15 Mar 2009 09:38:43 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Limno-000DLx-Ri; Sun, 15 Mar 2009 12:38:40 +0300 Message-ID: <49BCCC9D.30109@FreeBSD.org> Date: Sun, 15 Mar 2009 12:38:37 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dmitriy Demidov References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> In-Reply-To: <200903142031.53326.dima_bsd@inbox.lv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 15 Mar 2009 09:38:43 -0000 Dmitriy Demidov wrote: > Hi Luigi. Thank you for answer. > It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( But what's wrong with it? A fragment got from net, pass firewall and store. After all fragments we got, OS reassembly a packet and pass it through firewall again. -- Dixi. Sem. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 09:56:49 2009 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 EF633106566C for ; Sun, 15 Mar 2009 09:56:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id B04A98FC12 for ; Sun, 15 Mar 2009 09:56:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A43CD73098; Sun, 15 Mar 2009 11:02:06 +0100 (CET) Date: Sun, 15 Mar 2009 11:02:06 +0100 From: Luigi Rizzo To: Sergey Matveychuk Message-ID: <20090315100206.GA63505@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BCCC9D.30109@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, Dmitriy Demidov Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 15 Mar 2009 09:56:50 -0000 On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: > Dmitriy Demidov wrote: > >Hi Luigi. Thank you for answer. > >It is a big "surprise" for me that reassembling of IP datagrams is done > >not *before* they go into firewall, but *after* :( > > But what's wrong with it? A fragment got from net, pass firewall and > store. After all fragments we got, OS reassembly a packet and pass it > through firewall again. Currently we don't have a way to re-invoke the firewall after reassembly. In fact, we should probably provide hooks before and after reassembly, and use them in a configurable way. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 09:59:05 2009 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 B86E2106564A; Sun, 15 Mar 2009 09:59:05 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp6.apollo.lv (smtp6.apollo.lv [80.232.168.167]) by mx1.freebsd.org (Postfix) with ESMTP id 7122C8FC22; Sun, 15 Mar 2009 09:59:05 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from [87.110.84.86] (unknown [87.110.84.86]) by smtp6.apollo.lv (Postfix) with ESMTP id 4F2D720E55; Sun, 15 Mar 2009 11:59:17 +0200 (EET) From: Dmitriy Demidov To: Sergey Matveychuk Date: Sun, 15 Mar 2009 11:58:54 +0200 User-Agent: KMail/1.9.10 References: <200903132246.49159.dima_bsd@inbox.lv> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> In-Reply-To: <49BCCC9D.30109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903151158.54572.dima_bsd@inbox.lv> X-Lattelecom-MailScanner-Information: Please contact the ISP for more information X-Lattelecom-MailScanner-ID: 4F2D720E55.A309B X-Lattelecom-MailScanner: Found to be clean X-Lattelecom-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.901, required 5, BAYES_00 -2.60, RCVD_IN_PBL 0.91, RDNS_NONE 0.10, SPF_FAIL 0.69) X-Lattelecom-MailScanner-From: dima_bsd@inbox.lv X-Spam-Status: No Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 15 Mar 2009 09:59:06 -0000 On Sunday 15 March 2009, Sergey Matveychuk wrote: > Dmitriy Demidov wrote: > > Hi Luigi. Thank you for answer. > > It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( > > But what's wrong with it? A fragment got from net, pass firewall and > store. After all fragments we got, OS reassembly a packet and pass it > through firewall again. > >>it is not related to dynamic rules, but to the fact that >>that the firewall is called before reassembling packets. >>The info (port numbers especially) is not available >>in the fragments so the firewall cannot do anything. >>The only solution would be to call the firewall >>after reassembly. I am not sure if there is any work in progress >>for that. If I got it right from Luigi explanation, then problem we see here happens this way: ipfw receivs fragmented IP datagrams what contains splited UDP packet insight (IP-fragment1/UDP-head) + (IP-fragment2/UDP-tail), and it can not procead second one because of lack of UDP header? IP reassembling happens after ipfw? From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 10:40:18 2009 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 AE807106566C for ; Sun, 15 Mar 2009 10:40:18 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2878FC08 for ; Sun, 15 Mar 2009 10:40:18 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LinlR-000E6x-GX; Sun, 15 Mar 2009 13:40:17 +0300 Message-ID: <49BCDB0D.6070608@FreeBSD.org> Date: Sun, 15 Mar 2009 13:40:13 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> <20090315100206.GA63505@onelab2.iet.unipi.it> In-Reply-To: <20090315100206.GA63505@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Dmitriy Demidov Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 15 Mar 2009 10:40:18 -0000 Luigi Rizzo wrote: > On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: >> Dmitriy Demidov wrote: >>> Hi Luigi. Thank you for answer. >>> It is a big "surprise" for me that reassembling of IP datagrams is done >>> not *before* they go into firewall, but *after* :( >> But what's wrong with it? A fragment got from net, pass firewall and >> store. After all fragments we got, OS reassembly a packet and pass it >> through firewall again. > > Currently we don't have a way to re-invoke the firewall after > reassembly. In fact, we should probably provide hooks before and > after reassembly, and use them in a configurable way. It sounds like a security issue. We can construct any packet that pass through firewall? -- Dixi. Sem. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 15 11:12:00 2009 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 6ABDE106566B for ; Sun, 15 Mar 2009 11:12:00 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id 26F808FC1A for ; Sun, 15 Mar 2009 11:12:00 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LioG6-000EP1-QB; Sun, 15 Mar 2009 14:11:59 +0300 Message-ID: <49BCE276.1050509@FreeBSD.org> Date: Sun, 15 Mar 2009 14:11:50 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> <20090315100206.GA63505@onelab2.iet.unipi.it> <49BCDB0D.6070608@FreeBSD.org> In-Reply-To: <49BCDB0D.6070608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Dmitriy Demidov Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 15 Mar 2009 11:12:00 -0000 Sergey Matveychuk wrote: > Luigi Rizzo wrote: >> On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: >>> Dmitriy Demidov wrote: >>>> Hi Luigi. Thank you for answer. >>>> It is a big "surprise" for me that reassembling of IP datagrams is >>>> done not *before* they go into firewall, but *after* :( >>> But what's wrong with it? A fragment got from net, pass firewall and >>> store. After all fragments we got, OS reassembly a packet and pass it >>> through firewall again. >> >> Currently we don't have a way to re-invoke the firewall after >> reassembly. In fact, we should probably provide hooks before and >> after reassembly, and use them in a configurable way. > > It sounds like a security issue. We can construct any packet that pass > through firewall? > Well, I see a first fragment will be checked. But anyway I think the reassembled package must pass firewall again. -- Dixi. Sem. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 16 11:06:58 2009 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 2D857106568C for ; Mon, 16 Mar 2009 11:06:58 +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 1AB8C8FC1A for ; Mon, 16 Mar 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2GB6vqH043288 for ; Mon, 16 Mar 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2GB6uQ1043284 for freebsd-ipfw@FreeBSD.org; Mon, 16 Mar 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Mar 2009 11:06:56 GMT Message-Id: <200903161106.n2GB6uQ1043284@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, 16 Mar 2009 11:06:59 -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/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port 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 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 (cor 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 kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work 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/97504 ipfw [ipfw] IPFW Rules bug 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 kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION 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 56 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 09:06:51 2009 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 57A721065672 for ; Tue, 17 Mar 2009 09:06:51 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 990748FC14 for ; Tue, 17 Mar 2009 09:06:50 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 51854 invoked from network); 17 Mar 2009 08:40:08 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 17 Mar 2009 08:40:08 -0000 Message-ID: <49BF61E7.7020305@FreeBSD.org> Date: Tue, 17 Mar 2009 09:40:07 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> In-Reply-To: <20090313214327.GA1675@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Dmitriy Demidov Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 09:06:51 -0000 Luigi Rizzo ha scritto: > it is not related to dynamic rules, but to the fact that > that the firewall is called before reassembling packets. > The info (port numbers especially) is not available > in the fragments so the firewall cannot do anything. > The only solution would be to call the firewall > after reassembly. I am not sure if there is any work in progress > for that. FWIW pf has "traffic normalization" feature ("scrub" keyword), that reassembles packets before inspection. Unfortunately, it works with IPv4 packets, but lacks IPv6 support. -- Alex Dupre From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 15:12:42 2009 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 0E6C91065672 for ; Tue, 17 Mar 2009 15:12:42 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from mail0.tomato.it (mail0.tomato.it [213.92.0.53]) by mx1.freebsd.org (Postfix) with SMTP id 995178FC15 for ; Tue, 17 Mar 2009 15:12:31 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from ferret.tomato.lan (fast.tomato.it [62.101.64.91]) by mail0.tomato.it (Postfix) with ESMTP id 3982228423; Tue, 17 Mar 2009 15:57:13 +0100 (CET) Message-ID: <49BFB9B2.9090909@oltrelinux.com> Date: Tue, 17 Mar 2009 15:54:42 +0100 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.16 (X11/20080815) MIME-Version: 1.0 To: Alex Dupre References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> In-Reply-To: <49BF61E7.7020305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Dmitriy Demidov , Luigi Rizzo Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 15:12:42 -0000 Alex Dupre wrote: > Luigi Rizzo ha scritto: >> it is not related to dynamic rules, but to the fact that >> that the firewall is called before reassembling packets. >> The info (port numbers especially) is not available >> in the fragments so the firewall cannot do anything. >> The only solution would be to call the firewall >> after reassembly. I am not sure if there is any work in progress >> for that. > > FWIW pf has "traffic normalization" feature ("scrub" keyword), that > reassembles packets before inspection. Unfortunately, it works with > IPv4 packets, but lacks IPv6 support. > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], but if the idea of an explicit packet reassembly action sounds good, i could move the code over there. [*] actually the patch is really simple, it's just a call to ip_reass() with some glue code, but nonetheless it could be used more globally. -- bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 17:02:08 2009 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 1D921106567E for ; Tue, 17 Mar 2009 17:02:08 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from cohiba.eagle.ca (cohiba.eagle.ca [208.70.104.203]) by mx1.freebsd.org (Postfix) with ESMTP id B19338FC1A for ; Tue, 17 Mar 2009 17:02:07 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 46154 invoked by uid 89); 17 Mar 2009 16:35:26 -0000 Received: from unknown (HELO ?192.168.1.114?) (steveb@eagle.ca@208.70.104.100) by cohiba.eagle.ca with ESMTPA; 17 Mar 2009 16:35:26 -0000 Message-ID: <49BFD13F.8000608@ibctech.ca> Date: Tue, 17 Mar 2009 12:35:11 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Fwd: uRPF] 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: Tue, 17 Mar 2009 17:02:08 -0000 [ I tried this over at -net, but with no response, thought I'd try here] Hi everyone, I've implemented RTBH within our network, but I have one small issue. I've got one FreeBSD/Quagga edge router that has an interface which contains a default route out. Although this will change in the next while, at this time, it is preventing me from doing reverse path check, thereby breaking source-based black-holing. It appears to me that IPFW's verrevpath (and it's kin) do not provide the ability to perform the RPF check and allow default. Have there been any advancements in this regard? Am I missing something, or is there another approach to allowing default with reverse path? Regards, Steve _______________________________________________ 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-ipfw@FreeBSD.ORG Tue Mar 17 18:33:20 2009 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 227541065679; Tue, 17 Mar 2009 18:33:20 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp6.apollo.lv (smtp6.apollo.lv [80.232.168.167]) by mx1.freebsd.org (Postfix) with ESMTP id C4C3F8FC12; Tue, 17 Mar 2009 18:33:19 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from [87.110.84.86] (unknown [87.110.84.86]) by smtp6.apollo.lv (Postfix) with ESMTP id 4E548219EF; Tue, 17 Mar 2009 20:33:32 +0200 (EET) From: Dmitriy Demidov To: Paolo Pisati Date: Tue, 17 Mar 2009 20:33:09 +0200 User-Agent: KMail/1.9.10 References: <200903132246.49159.dima_bsd@inbox.lv> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> In-Reply-To: <49BFB9B2.9090909@oltrelinux.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903172033.09731.dima_bsd@inbox.lv> X-Lattelecom-MailScanner-Information: Please contact the ISP for more information X-Lattelecom-MailScanner-ID: 4E548219EF.4BED5 X-Lattelecom-MailScanner: Found to be clean X-Lattelecom-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.901, required 5, BAYES_00 -2.60, RCVD_IN_PBL 0.91, RDNS_NONE 0.10, SPF_FAIL 0.69) X-Lattelecom-MailScanner-From: dima_bsd@inbox.lv X-Spam-Status: No Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 18:33:20 -0000 On Tuesday 17 March 2009, Paolo Pisati wrote: > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], > but if the idea of an explicit packet reassembly action sounds good, i > could move the code over there. > > [*] actually the patch is really simple, it's just a call to ip_reass() > with some glue code, but nonetheless it could be used more globally. It's sounds like the thing I'm looking for! How hard it would be to make it? If it is unacceptable to turn it on by default (for some reasons, if any) then can it be implemented as additional ipfw rule allowing to turn him on/off when needed? Something like: ipfw add 100 scrub-ip ip from any to me From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 18:56:03 2009 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 78CF1106566B; Tue, 17 Mar 2009 18:56:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D14B28FC0C; Tue, 17 Mar 2009 18:56:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6330673098; Tue, 17 Mar 2009 20:01:23 +0100 (CET) Date: Tue, 17 Mar 2009 20:01:23 +0100 From: Luigi Rizzo To: Paolo Pisati Message-ID: <20090317190123.GB89417@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BFB9B2.9090909@oltrelinux.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 18:56:03 -0000 On Tue, Mar 17, 2009 at 03:54:42PM +0100, Paolo Pisati wrote: > Alex Dupre wrote: > >Luigi Rizzo ha scritto: > >>it is not related to dynamic rules, but to the fact that > >>that the firewall is called before reassembling packets. > >>The info (port numbers especially) is not available > >>in the fragments so the firewall cannot do anything. > >>The only solution would be to call the firewall > >>after reassembly. I am not sure if there is any work in progress > >>for that. > > > >FWIW pf has "traffic normalization" feature ("scrub" keyword), that > >reassembles packets before inspection. Unfortunately, it works with > >IPv4 packets, but lacks IPv6 support. > > > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], > but if the idea of an explicit packet reassembly action sounds good, i > could move the code over there. > > [*] actually the patch is really simple, it's just a call to ip_reass() > with some glue code, but nonetheless it could be used more globally. Thinking more about it, i believe that calling reass as an explicit firewall action is useless, because if ip_reass fails due to lack of all fragments you are back to square one: what do I do with this fragment ? And the answer can only be the same that you would implement without the mechanism: unconditionally accept all fragments past the first one, and do the actual filtering on the first fragment. If you drop the fragments, you would be unable to rebuild the full packet. The only thing that would actually make a difference, i believe, is the ability to call the firewall after ip_reass() instead of just before (of course you'd need some microinstruction to check who is calling you, and make different decisions in the various cases). cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 22:14:09 2009 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 7F7C1106566B for ; Tue, 17 Mar 2009 22:14:09 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from averell.mail.tiscali.it (averell.mail.tiscali.it [213.205.33.55]) by mx1.freebsd.org (Postfix) with ESMTP id 063B88FC19 for ; Tue, 17 Mar 2009 22:14:08 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from newluxor.wired.org (94.36.82.161) by averell.mail.tiscali.it (8.0.022) id 499F0393010A5C24; Tue, 17 Mar 2009 23:02:55 +0100 Message-ID: <49C01E08.9050709@oltrelinux.com> Date: Tue, 17 Mar 2009 23:02:48 +0100 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.18 (X11/20081214) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> In-Reply-To: <20090317190123.GB89417@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 22:14:10 -0000 Luigi Rizzo wrote: > > Thinking more about it, i believe that calling reass as an explicit > firewall action is useless, because if ip_reass fails due to lack of > all fragments you are back to square one: > what do I do with this fragment ? > AFAIK ip_reass() never fails: if it's the last fragment it reassembles the packet and return it, else it queues the fragment for later reassembly. and i guess we must extend ip fragment detection together with the reass action because 'frag' matches only packet with a non-zero offset (aka not the first fragment). bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 22:29:50 2009 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 7DB8B106566C; Tue, 17 Mar 2009 22:29:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 32B658FC16; Tue, 17 Mar 2009 22:29:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D6BD4730A1; Tue, 17 Mar 2009 23:35:11 +0100 (CET) Date: Tue, 17 Mar 2009 23:35:11 +0100 From: Luigi Rizzo To: Paolo Pisati Message-ID: <20090317223511.GB95451@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C01E08.9050709@oltrelinux.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 22:29:50 -0000 On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote: > Luigi Rizzo wrote: > > > >Thinking more about it, i believe that calling reass as an explicit > >firewall action is useless, because if ip_reass fails due to lack of > >all fragments you are back to square one: > > what do I do with this fragment ? > > > > AFAIK ip_reass() never fails: if it's the last fragment it reassembles > the packet and return it, else it queues the fragment for later > reassembly. Ok then we may have a plan: you could do is implement REASS as an action (not as a microinstruction), with the following behaviour: - if the packet is a complete one, the rule behaves as a "count" (i.e. the firewall continues with the next rule); - if the packet is a fragment and can be reassembled, the rule behaves as a "count" and the mbuf is replaced with the full packet; - if the packet is a fragment and cannot be reassembled, the rule behaves as a "drop" (i.e. processing stops) and the packet is swallowed by ipfw. This seems a useful behaviour, but it must be documented very clearly because it is not completely intuitive. Perhaps we should find a more descriptive name. Good progress! cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 17 22:39:37 2009 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 F081C1065674 for ; Tue, 17 Mar 2009 22:39:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id CEE168FC17 for ; Tue, 17 Mar 2009 22:39:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id F25736D9ED; Tue, 17 Mar 2009 15:39:38 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id E1CCE2D601E; Tue, 17 Mar 2009 15:39:36 -0700 (PDT) Message-ID: <49C026B1.8010108@elischer.org> Date: Tue, 17 Mar 2009 15:39:45 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> In-Reply-To: <20090317223511.GB95451@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 22:39:38 -0000 Luigi Rizzo wrote: > On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote: >> Luigi Rizzo wrote: >>> Thinking more about it, i believe that calling reass as an explicit >>> firewall action is useless, because if ip_reass fails due to lack of >>> all fragments you are back to square one: >>> what do I do with this fragment ? >>> >> AFAIK ip_reass() never fails: if it's the last fragment it reassembles >> the packet and return it, else it queues the fragment for later >> reassembly. > > Ok then we may have a plan: > > you could do is implement REASS as an action (not as a microinstruction), > with the following behaviour: > > - if the packet is a complete one, the rule behaves as a "count" > (i.e. the firewall continues with the next rule); > > - if the packet is a fragment and can be reassembled, the rule > behaves as a "count" and the mbuf is replaced with the full packet; > > - if the packet is a fragment and cannot be reassembled, the > rule behaves as a "drop" (i.e. processing stops) > and the packet is swallowed by ipfw. > > This seems a useful behaviour, but it must be documented very > clearly because it is not completely intuitive. Perhaps we should > find a more descriptive name. So what is the behaviour when you reassemble a 5K packet, and then it has to be forwarded out another interface with 1500 MTU. > > Good progress! > > cheers > luigi > _______________________________________________ > 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 Tue Mar 17 23:07:01 2009 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 2BDD9106566B; Tue, 17 Mar 2009 23:07:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D8D238FC13; Tue, 17 Mar 2009 23:07:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 86095730A1; Wed, 18 Mar 2009 00:12:22 +0100 (CET) Date: Wed, 18 Mar 2009 00:12:22 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20090317231222.GD95451@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C026B1.8010108@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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: Tue, 17 Mar 2009 23:07:01 -0000 On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: ... > >Ok then we may have a plan: > > > >you could do is implement REASS as an action (not as a microinstruction), > >with the following behaviour: > > > >- if the packet is a complete one, the rule behaves as a "count" > > (i.e. the firewall continues with the next rule); > > > >- if the packet is a fragment and can be reassembled, the rule > > behaves as a "count" and the mbuf is replaced with the full packet; > > > >- if the packet is a fragment and cannot be reassembled, the > > rule behaves as a "drop" (i.e. processing stops) > > and the packet is swallowed by ipfw. > > > >This seems a useful behaviour, but it must be documented very > >clearly because it is not completely intuitive. Perhaps we should > >find a more descriptive name. > > So what is the behaviour when you reassemble a 5K packet, > and then it has to be forwarded out another interface with 1500 MTU. Good point. One option would be that when REASS is called from the output path, it always act as "count" and never calls ip_reass() Would that work ? The firewall in the output path is called before fragment, locally generated packets are not fragmented, and if don't want stray fragment you should have already called "reass" in the inbound path through the firewall ? cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 01:44:14 2009 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 3000E106566B for ; Wed, 18 Mar 2009 01:44:14 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from mail.qwe.net.ua (qwe.net.ua [80.245.118.211]) by mx1.freebsd.org (Postfix) with ESMTP id D55798FC1B for ; Wed, 18 Mar 2009 01:44:13 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from localhost (localhost.qwe.net.ua [127.0.0.1]) by mail.qwe.net.ua (Postfix) with ESMTP id 5B7FAF06F for ; Wed, 18 Mar 2009 03:21:35 +0200 (EET) Received: from mail.qwe.net.ua ([127.0.0.1]) by localhost (qwe.net.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D9c9QlSMW2cB for ; Wed, 18 Mar 2009 03:21:32 +0200 (EET) Received: from [10.2.1.1] (unknown [10.2.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.qwe.net.ua (Postfix) with ESMTP id 27553C304 for ; Wed, 18 Mar 2009 03:21:32 +0200 (EET) Message-ID: <49C04CA3.1070100@qwe.net.ua> Date: Wed, 18 Mar 2009 03:21:39 +0200 From: Eugene L Kovalenja User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.0: dummynet 99% cpu 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, 18 Mar 2009 01:44:14 -0000 Hello. My OS: FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET 2008 root@***:/usr/src/sys/i386/compile/QWEKRN70 i386 Machine: HP Proliant DL560 (Xeon 2.5GHzX8, 4Gb RAM) /etc/sysctl.conf kern.polling.enable=0 net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 net.inet.icmp.icmplim=100 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.tcp.msl=15000 net.inet.ip.fastforwarding=1 net.inet.ip.maxfragsperpacket=45 net.inet.tcp.log_in_vain=0 kern.ipc.maxsockets=204800 kern.ipc.maxsockbuf=16777216 kern.polling.each_burst=150 kern.polling.burst_max=1000 net.inet.tcp.syncookies=1 kern.ipc.nmbclusters=262144 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 security.bsd.unprivileged_read_msgbuf=0 net.inet.ip.random_id=1 kern.logsigexit=0 kern.ipc.somaxconn=24096 net.inet.ip.intr_queue_maxlen=1024 net.inet.tcp.mssdflt=1460 net.inet.tcp.slowstart_flightsize=54 net.inet.ip.fw.one_pass=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 kern.maxfilesperproc=104856 kern.maxfiles=65535 net.inet.tcp.rfc1323=1 net.inet.ip.dummynet.hash_size=512 net.graph.maxdgram=128000 net.graph.recvspace=128000 net.inet.ip.intr_queue_maxlen=10240 I'm use this machine as VPN-server for access my clients into Internet. VPN-server: mpd4.3 Shaper: dummynet (pipes) Example of shaper rules: 01111 0 0 pipe 1231 ip from table(123) to any via ng* 01111 0 0 pipe 1232 ip from any to table(123) via ng* Pipes: ipfw pipe 1231 config bw XXXXKbit/s mask src-ip 0xffffffff ipfw pipe 1232 config bw XXXXKbit/s mask dst-ip 0xffffffff Time in three days traffic via ipfw doesn't go. In top: 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet (this is example, not copy\paste) Also sw1: net increases from 5-10% to 30-35%... I am helped only by reboot. In what can consist the problem? Thanks. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 10:23:20 2009 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 1ED89106566B for ; Wed, 18 Mar 2009 10:23:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95A5B8FC08 for ; Wed, 18 Mar 2009 10:23:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n2IAMsW5038027; Wed, 18 Mar 2009 11:23:18 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n2IAMsWs038026; Wed, 18 Mar 2009 11:22:54 +0100 (CET) (envelope-from olli) Date: Wed, 18 Mar 2009 11:22:54 +0100 (CET) Message-Id: <200903181022.n2IAMsWs038026@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, qwe@qwe.net.ua In-Reply-To: <49C04CA3.1070100@qwe.net.ua> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 18 Mar 2009 11:23:18 +0100 (CET) Cc: Subject: Re: FreeBSD 7.0: dummynet 99% cpu X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG, qwe@qwe.net.ua List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 10:23:20 -0000 Eugene L Kovalenja wrote: > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > [...] > Time in three days traffic via ipfw doesn't go. In top: > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > (this is example, not copy\paste) There are a few problems that have been fixed (or worked around) after the release of 7.0. For example, look at PR kern/113548 which has a work-around in 7.1. Your problem description sounds like it could be caused by the same problem. Therefore I recommend you update to 7.1 or 7-stable. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch鋐tsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M黱- chen, HRB 125758, Gesch鋐tsf黨rer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 10:34:09 2009 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 BE6B1106564A for ; Wed, 18 Mar 2009 10:34:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41B228FC17 for ; Wed, 18 Mar 2009 10:34:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n2IAXiXo038439; Wed, 18 Mar 2009 11:34:08 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n2IAXieV038438; Wed, 18 Mar 2009 11:33:44 +0100 (CET) (envelope-from olli) Date: Wed, 18 Mar 2009 11:33:44 +0100 (CET) Message-Id: <200903181033.n2IAXieV038438@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, rizzo@iet.unipi.it In-Reply-To: <20090317231222.GD95451@onelab2.iet.unipi.it> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 18 Mar 2009 11:34:08 +0100 (CET) Cc: Subject: Re: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets? 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, 18 Mar 2009 10:34:10 -0000 I'm just curious ... Is it really worth the effort to add fragment reassembly to IPFW? What advantage does it have? It would be much easier to simply pass all fragments with offset > 1, and drop all fragments with offset 0 that are smaller than a certain reasonable minimum length. What would be the problem with this approach? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch鋐tsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M黱- chen, HRB 125758, Gesch鋐tsf黨rer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 15:52:42 2009 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 6F125106568E for ; Wed, 18 Mar 2009 15:52:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB5C8FC27 for ; Wed, 18 Mar 2009 15:52:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CA33D101C01; Wed, 18 Mar 2009 08:52:27 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id AE11C2D600D; Wed, 18 Mar 2009 08:52:09 -0700 (PDT) Message-ID: <49C118B2.5050002@elischer.org> Date: Wed, 18 Mar 2009 08:52:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> <20090317231222.GD95451@onelab2.iet.unipi.it> In-Reply-To: <20090317231222.GD95451@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 18 Mar 2009 15:52:42 -0000 Luigi Rizzo wrote: > On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: > ... >>> Ok then we may have a plan: >>> >>> you could do is implement REASS as an action (not as a microinstruction), >>> with the following behaviour: >>> >>> - if the packet is a complete one, the rule behaves as a "count" >>> (i.e. the firewall continues with the next rule); >>> >>> - if the packet is a fragment and can be reassembled, the rule >>> behaves as a "count" and the mbuf is replaced with the full packet; >>> >>> - if the packet is a fragment and cannot be reassembled, the >>> rule behaves as a "drop" (i.e. processing stops) >>> and the packet is swallowed by ipfw. >>> >>> This seems a useful behaviour, but it must be documented very >>> clearly because it is not completely intuitive. Perhaps we should >>> find a more descriptive name. >> So what is the behaviour when you reassemble a 5K packet, >> and then it has to be forwarded out another interface with 1500 MTU. > > Good point. One option would be that when REASS is called from the > output path, it always act as "count" and never calls ip_reass() > > Would that work ? The firewall in the output path is called before > fragment, locally generated packets are not fragmented, and if > don't want stray fragment you should have already called "reass" > in the inbound path through the firewall ? yeah but what if you reassemble on input, and then the packet is routed? > > cheers > luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 16:10:40 2009 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 4B86C1065687; Wed, 18 Mar 2009 16:10:40 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id DE64D8FC1B; Wed, 18 Mar 2009 16:10:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E85CD730A1; Wed, 18 Mar 2009 17:15:24 +0100 (CET) Date: Wed, 18 Mar 2009 17:15:24 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20090318161524.GA11771@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> <20090317231222.GD95451@onelab2.iet.unipi.it> <49C118B2.5050002@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C118B2.5050002@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? 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, 18 Mar 2009 16:10:41 -0000 On Wed, Mar 18, 2009 at 08:52:18AM -0700, Julian Elischer wrote: > Luigi Rizzo wrote: > >On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: > >... > >>>Ok then we may have a plan: > >>> > >>>you could do is implement REASS as an action (not as a microinstruction), > >>>with the following behaviour: > >>> > >>>- if the packet is a complete one, the rule behaves as a "count" > >>> (i.e. the firewall continues with the next rule); > >>> > >>>- if the packet is a fragment and can be reassembled, the rule > >>> behaves as a "count" and the mbuf is replaced with the full packet; > >>> > >>>- if the packet is a fragment and cannot be reassembled, the > >>> rule behaves as a "drop" (i.e. processing stops) > >>> and the packet is swallowed by ipfw. > >>> > >>>This seems a useful behaviour, but it must be documented very > >>>clearly because it is not completely intuitive. Perhaps we should > >>>find a more descriptive name. > >>So what is the behaviour when you reassemble a 5K packet, > >>and then it has to be forwarded out another interface with 1500 MTU. > > > >Good point. One option would be that when REASS is called from the > >output path, it always act as "count" and never calls ip_reass() > > > >Would that work ? The firewall in the output path is called before > >fragment, locally generated packets are not fragmented, and if > >don't want stray fragment you should have already called "reass" > >in the inbound path through the firewall ? > > yeah but what if you reassemble on input, and then the packet is routed? it should work -- ip_output() gets the full packet, the firewall is called on line 441 before ip_fragment() which is on line 568. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 19 02:51:58 2009 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 90C001065675 for ; Thu, 19 Mar 2009 02:51:58 +0000 (UTC) (envelope-from linzhao@ustc.edu.cn) Received: from ustc.edu.cn (smtp.ustc.edu.cn [202.38.64.16]) by mx1.freebsd.org (Postfix) with SMTP id 60BFD8FC0A for ; Thu, 19 Mar 2009 02:51:55 +0000 (UTC) (envelope-from linzhao@ustc.edu.cn) Received: (eyou send program); Thu, 19 Mar 2009 10:36:15 +0800 Message-ID: <437430175.25503@ustc.edu.cn> Received: from 202.38.70.144 by email.ustc.edu.cn with HTTP; Thu, 19 Mar 2009 10:36:15 +0800 X-WebMAIL-MUA: [202.38.70.144] From: "Lin Zhao" To: freebsd-ipfw@freebsd.org Date: Thu, 19 Mar 2009 10:36:15 +0800 X-Priority: 3 Content-Type: text/plain Subject: pls help on 3 interfaces X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lin Zhao List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 02:51:58 -0000 hi all, wish my english is enough :-) my freebsd has 3 interfaces, like this, ---- ----switch1 | ---------- fxp0 | | | |--------- internal |--------|freebsd71 | | rl0 | |--------- | ---------- fxp1 | ---- ----switch2 we're in the internal and want to visit outside we use fxp0 for default outside address and it works well but for some reason, i want to use fxp1 for some special outside address how can i do for it? thanks a lot. Lin Zhao SCGY,USTC,PRC From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 19 03:49:40 2009 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 A4A4E106566C for ; Thu, 19 Mar 2009 03:49:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5788FC13 for ; Thu, 19 Mar 2009 03:49:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8CAB6D17C; Wed, 18 Mar 2009 20:49:40 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B696C2D600E; Wed, 18 Mar 2009 20:49:38 -0700 (PDT) Message-ID: <49C1C0D8.2060206@elischer.org> Date: Wed, 18 Mar 2009 20:49:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lin Zhao References: <437430175.25503@ustc.edu.cn> In-Reply-To: <437430175.25503@ustc.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: pls help on 3 interfaces 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: Thu, 19 Mar 2009 03:49:41 -0000 Lin Zhao wrote: > hi all, wish my english is enough :-) > my freebsd has 3 interfaces, like this, > > ---- ----switch1 > | ---------- fxp0 | > | | |--------- > internal |--------|freebsd71 | > | rl0 | |--------- > | ---------- fxp1 | > ---- ----switch2 first set your routingtable so that teh 'special' addresses go via switch2, then set up NAT as follows: like this: ---- ----switch1 | ---------- fxp0 | | | NAT1(*)|--------- internal |--------|freebsd71 | | rl0 | NAT2|--------- | ---------- fxp1 | ---- ----switch2 (*) If you want, NAT1 may be left out if you use routable addresses on your internal network. The reason for the NAT is to make sure that outgoing packets have a source address that will make the return packets come back through switch2, otherwise, even if you have a route making the outgoing packets go via switch2, the return packets will still comeback via switch1. > > we're in the internal and want to visit outside > we use fxp0 for default outside address and it works well > but for some reason, i want to use fxp1 for some special outside address > how can i do for it? > thanks a lot. > > > Lin Zhao > SCGY,USTC,PRC > > > _______________________________________________ > 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 Thu Mar 19 03:49:57 2009 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 22CF61065672 for ; Thu, 19 Mar 2009 03:49:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0856B8FC16 for ; Thu, 19 Mar 2009 03:49:56 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.213.128] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id n2J3NvVF061481; Wed, 18 Mar 2009 23:23:59 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-ipfw@freebsd.org, Lin Zhao Date: Wed, 18 Mar 2009 23:23:56 -0400 User-Agent: KMail/1.9.10 References: <437430175.25503@ustc.edu.cn> In-Reply-To: <437430175.25503@ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903182323.56585.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: Re: pls help on 3 interfaces 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: Thu, 19 Mar 2009 03:49:57 -0000 On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: > hi all, wish my english is enough :-) > my freebsd has 3 interfaces, like this, > > ---- ----switch1 > > | ---------- fxp0 | > | > | | |--------- > > internal |--------|freebsd71 | > > | rl0 | |--------- > | ---------- fxp1 | > > ---- ----switch2 > > we're in the internal and want to visit outside > we use fxp0 for default outside address and it works well > but for some reason, i want to use fxp1 for some special outside > address how can i do for it? > thanks a lot. Is the FreeBSD box performing network address translation (NAT)? I'm going to assume that it is and everything is being aliased through fxp0. I'm also assuming you're using ipfw since you wrote to the ipfw list. If the IP addresses which you'd like to reach via fxp1 are static, you should be able to do something like the following: Configure static routes on the FreeBSD machine for the the special outside addresses using the gateway of fxp1's network as the router. Configure an additional NAT rule (if still using natd now might be a good time to switch to in-kernel ipfw NAT..) to alias through fxp1. Configure ipfw to direct traffic to/from the special outside addresses to the new NAT instance instead of the default. I actually used a similar setup recently. If you care to confirm my assumptions above I can give you a more step-by-step guide. JN From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 19 07:13:53 2009 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 9BA281065672 for ; Thu, 19 Mar 2009 07:13:53 +0000 (UTC) (envelope-from linzhao@ustc.edu.cn) Received: from ustc.edu.cn (smtp.ustc.edu.cn [202.38.64.16]) by mx1.freebsd.org (Postfix) with SMTP id 855F98FC16 for ; Thu, 19 Mar 2009 07:13:50 +0000 (UTC) (envelope-from linzhao@ustc.edu.cn) Received: (eyou send program); Thu, 19 Mar 2009 15:14:49 +0800 Message-ID: <437446889.08051@ustc.edu.cn> Received: from 202.38.70.144 by email.ustc.edu.cn with HTTP; Thu, 19 Mar 2009 15:14:49 +0800 X-WebMAIL-MUA: [202.38.70.144] From: "Lin Zhao" To: lists@jnielsen.net, freebsd-ipfw@freebsd.org Date: Thu, 19 Mar 2009 15:14:49 +0800 X-Priority: 3 Content-Type: text/plain Cc: Subject: Re: pls help on 3 interfaces X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lin Zhao List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 07:13:53 -0000 too much thx for Julian Elischer & John Nielsen..... i've tried it, and it seems working now, but i don't know if i'm right in setting natd2.... i just add one line in /etc/services as "natd2 8669" and run a command: natd -n fxp1 -p 8669 seems so stupid Lin 在您的来信中曾经提到: >From: John Nielsen >Reply-To: >To: freebsd-ipfw@freebsd.org, Lin Zhao >Subject: Re: pls help on 3 interfaces >Date:Wed, 18 Mar 2009 23:23:56 -0400 > >On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: > > hi all, wish my english is enough :-) > > my freebsd has 3 interfaces, like this, > > > > ---- ----switch1 > > > > | ---------- fxp0 | > > | > > | | |--------- > > > > internal |--------|freebsd71 | > > > > | rl0 | |--------- > > | ---------- fxp1 | > > > > ---- ----switch2 > > > > we're in the internal and want to visit outside > > we use fxp0 for default outside address and it works well > > but for some reason, i want to use fxp1 for some special outside > > address how can i do for it? > > thanks a lot. > > Is the FreeBSD box performing network address translation (NAT)? I'm going > to assume that it is and everything is being aliased through fxp0. I'm > also assuming you're using ipfw since you wrote to the ipfw list. > > If the IP addresses which you'd like to reach via fxp1 are static, you > should be able to do something like the following: > > Configure static routes on the FreeBSD machine for the the special outside > addresses using the gateway of fxp1's network as the router. > Configure an additional NAT rule (if still using natd now might be a good > time to switch to in-kernel ipfw NAT..) to alias through fxp1. > Configure ipfw to direct traffic to/from the special outside addresses to > the new NAT instance instead of the default. > > I actually used a similar setup recently. If you care to confirm my > assumptions above I can give you a more step-by-step guide. > > JN > > _______________________________________________ > 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 Thu Mar 19 07:34:59 2009 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 70D511065672 for ; Thu, 19 Mar 2009 07:34:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 55B8B8FC12 for ; Thu, 19 Mar 2009 07:34:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A57E5C362; Thu, 19 Mar 2009 00:34:35 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A01D62D6004; Thu, 19 Mar 2009 00:34:34 -0700 (PDT) Message-ID: <49C1F593.2050009@elischer.org> Date: Thu, 19 Mar 2009 00:34:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lin Zhao References: <437446889.08051@ustc.edu.cn> In-Reply-To: <437446889.08051@ustc.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, lists@jnielsen.net Subject: Re: pls help on 3 interfaces 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: Thu, 19 Mar 2009 07:34:59 -0000 Lin Zhao wrote: > too much thx for Julian Elischer & John Nielsen..... > i've tried it, and it seems working now, > but i don't know if i'm right in setting natd2.... > i just add one line in /etc/services as "natd2 8669" > and run a command: natd -n fxp1 -p 8669 > seems so stupid. I assume you mean "simple" instead of stupid... :-) I don't think you need natd2 in /etc/services... but as long as the ipfw and natd agree in the port number it should work. You didn't say if you have nat already. but if you do then I believe natd can do more than one nat with a single instance now. (phk added that some time ago) but I have never done it, so I can not tell you how... read the man page... also the in-kernel nat available in ipfw can do this and you can also do multiple NATS with that too but once again, I haven't done it myself. > > Lin > > 在您的来信中曾经提到: >> From: John Nielsen >> Reply-To: >> To: freebsd-ipfw@freebsd.org, Lin Zhao >> Subject: Re: pls help on 3 interfaces >> Date:Wed, 18 Mar 2009 23:23:56 -0400 >> >> On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: >>> hi all, wish my english is enough :-) >>> my freebsd has 3 interfaces, like this, >>> >>> ---- ----switch1 >>> >>> | ---------- fxp0 | >>> | >>> | | |--------- >>> >>> internal |--------|freebsd71 | >>> >>> | rl0 | |--------- >>> | ---------- fxp1 | >>> >>> ---- ----switch2 >>> >>> we're in the internal and want to visit outside >>> we use fxp0 for default outside address and it works well >>> but for some reason, i want to use fxp1 for some special outside >>> address how can i do for it? >>> thanks a lot. >> Is the FreeBSD box performing network address translation (NAT)? I'm going >> to assume that it is and everything is being aliased through fxp0. I'm >> also assuming you're using ipfw since you wrote to the ipfw list. >> >> If the IP addresses which you'd like to reach via fxp1 are static, you >> should be able to do something like the following: >> >> Configure static routes on the FreeBSD machine for the the special outside >> addresses using the gateway of fxp1's network as the router. >> Configure an additional NAT rule (if still using natd now might be a good >> time to switch to in-kernel ipfw NAT..) to alias through fxp1. >> Configure ipfw to direct traffic to/from the special outside addresses to >> the new NAT instance instead of the default. >> >> I actually used a similar setup recently. If you care to confirm my >> assumptions above I can give you a more step-by-step guide. >> >> JN >> >> _______________________________________________ >> 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" >> > > > _______________________________________________ > 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 Thu Mar 19 19:29:06 2009 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 9CF671065672 for ; Thu, 19 Mar 2009 19:29:06 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp4.apollo.lv (smtp4.apollo.lv [80.232.168.199]) by mx1.freebsd.org (Postfix) with ESMTP id 227128FC0C for ; Thu, 19 Mar 2009 19:29:05 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Virus-Scanned: by cgpav Received: from [81.198.144.211] ([81.198.144.211] verified) by smtp4.apollo.lv (CommuniGate Pro SMTP 5.2.3) with ESMTP id 306895827; Thu, 19 Mar 2009 21:29:04 +0200 From: Dmitriy Demidov To: freebsd-ipfw@freebsd.org Date: Thu, 19 Mar 2009 21:29:03 +0200 User-Agent: KMail/1.9.10 References: <200903181033.n2IAXieV038438@lurza.secnetix.de> In-Reply-To: <200903181033.n2IAXieV038438@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903192129.03360.dima_bsd@inbox.lv> Cc: Oliver Fromme Subject: Re: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets? 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: Thu, 19 Mar 2009 19:29:07 -0000 On Wednesday 18 March 2009, Oliver Fromme wrote: > I'm just curious ... Is it really worth the effort to add > fragment reassembly to IPFW? What advantage does it have? > > It would be much easier to simply pass all fragments with > offset > 1, and drop all fragments with offset 0 that are > smaller than a certain reasonable minimum length. What > would be the problem with this approach? > > Best regards > Oliver Please wait... If I got it right (and dont missing something) then this rule: ipfw add allow ip from any to me frag have dissadvantage - I'm unabled to filter data by UDP/TCP ports. All IP packets is just passing through firewall to me. No UDP/TCP filtering here? From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 20 03:42:44 2009 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 8AAC6106564A for ; Fri, 20 Mar 2009 03:42:44 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from mail.qwe.net.ua (qwe.net.ua [80.245.118.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCCB8FC12 for ; Fri, 20 Mar 2009 03:42:43 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from localhost (localhost.qwe.net.ua [127.0.0.1]) by mail.qwe.net.ua (Postfix) with ESMTP id 276A5DC50 for ; Fri, 20 Mar 2009 05:42:42 +0200 (EET) Received: from mail.qwe.net.ua ([127.0.0.1]) by localhost (qwe.net.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ePcZTGgeqlir for ; Fri, 20 Mar 2009 05:42:39 +0200 (EET) Received: from [10.2.1.1] (unknown [10.2.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.qwe.net.ua (Postfix) with ESMTP id 3080FDC6F for ; Fri, 20 Mar 2009 05:42:38 +0200 (EET) Message-ID: <49C310A9.6020102@qwe.net.ua> Date: Fri, 20 Mar 2009 05:42:33 +0200 From: Eugene L Kovalenja User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG References: <200903181022.n2IAMsWs038026@lurza.secnetix.de> In-Reply-To: <200903181022.n2IAMsWs038026@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD 7.0: dummynet 99% cpu 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, 20 Mar 2009 03:42:44 -0000 Oliver Fromme ?????: > Eugene L Kovalenja wrote: > > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > > [...] > > Time in three days traffic via ipfw doesn't go. In top: > > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > > (this is example, not copy\paste) > > There are a few problems that have been fixed (or worked > around) after the release of 7.0. For example, look at > PR kern/113548 which has a work-around in 7.1. Your > problem description sounds like it could be caused by > the same problem. > > Therefore I recommend you update to 7.1 or 7-stable. > > Best regards > Oliver > > Hello. System updated to: [root@taurus /usr/home/qwe]# uname -a FreeBSD *** 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Thu Mar 19 16:31:53 EET 2009 root@***:/usr/obj/usr/src/sys/QWEKRN70 i386 but once trouble has repeated (30 mins ago). After that I change my sysctl variables: net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.debug=1 net.inet.ip.dummynet.hash_size=16384 (from 512) What can I'll to do? Sorry for my bad English :( From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 20 09:15:45 2009 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 315C5106564A for ; Fri, 20 Mar 2009 09:15:45 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id DD9B48FC15 for ; Fri, 20 Mar 2009 09:15:44 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LkapK-000Kzx-K6; Fri, 20 Mar 2009 12:15:42 +0300 Message-ID: <49C35EB3.6040508@FreeBSD.org> Date: Fri, 20 Mar 2009 12:15:31 +0300 From: Sergey Matveyhcuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eugene L Kovalenja References: <49C04CA3.1070100@qwe.net.ua> In-Reply-To: <49C04CA3.1070100@qwe.net.ua> Content-Type: multipart/mixed; boundary="------------050200050702040508040404" Cc: freebsd-ipfw@freebsd.org Subject: Re: FreeBSD 7.0: dummynet 99% cpu 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, 20 Mar 2009 09:15:48 -0000 This is a multi-part message in MIME format. --------------050200050702040508040404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Could you test an included patch? Eugene L Kovalenja wrote: > > Time in three days traffic via ipfw doesn't go. In top: > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > (this is example, not copy\paste) > > Also sw1: net increases from 5-10% to 30-35%... > > I am helped only by reboot. > > In what can consist the problem? > --------------050200050702040508040404 Content-Type: text/plain; name="dummynet.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dummynet.patch" LS0tIHN5cy9uZXRpbmV0L2lwX2R1bW15bmV0LmMub3JpZwkyMDA5LTAzLTIwIDEyOjA4OjQ3 LjAwMDAwMDAwMCArMDMwMAorKysgc3lzL25ldGluZXQvaXBfZHVtbXluZXQuYwkyMDA5LTAz LTIwIDEyOjA5OjMxLjAwMDAwMDAwMCArMDMwMApAQCAtMTQ1LDggKzE0NSw4IEBACiBzdGF0 aWMgdm9pZAlyZWFkeV9ldmVudF93ZnEoc3RydWN0IGRuX3BpcGUgKnAsIHN0cnVjdCBtYnVm ICoqaGVhZCwKIAkJICAgIHN0cnVjdCBtYnVmICoqdGFpbCk7CiAKLSNkZWZpbmUJSEFTSFNJ WkUJMTYKLSNkZWZpbmUJSEFTSChudW0pCSgoKChudW0pID4+IDgpIF4gKChudW0pID4+IDQp IF4gKG51bSkpICYgMHgwZikKKyNkZWZpbmUJSEFTSFNJWkUJMjU1CisjZGVmaW5lCUhBU0go bnVtKQkoKCgobnVtKSA+PiA4KSBeICgobnVtKSA+PiA0KSBeIChudW0pKSAmIDB4ZmYpCiBz dGF0aWMgc3RydWN0IGRuX3BpcGVfaGVhZAlwaXBlaGFzaFtIQVNIU0laRV07CS8qIGFsbCBw aXBlcyAqLwogc3RhdGljIHN0cnVjdCBkbl9mbG93X3NldF9oZWFkCWZsb3dzZXRoYXNoW0hB U0hTSVpFXTsJLyogYWxsIGZsb3dzZXRzICovCiAK --------------050200050702040508040404-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 20 15:53:26 2009 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 49BA01065675 for ; Fri, 20 Mar 2009 15:53:26 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 0C03A8FC13 for ; Fri, 20 Mar 2009 15:53:25 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from [192.168.1.2] (e179073198.adsl.alicedsl.de [85.179.73.198]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id D734E700D477 for ; Fri, 20 Mar 2009 16:53:24 +0100 (CET) Message-ID: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> Date: Fri, 20 Mar 2009 16:53:26 +0100 From: Sebastian Mellmann User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: ipfw dummynet - delay distributions when using config masks 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, 20 Mar 2009 15:53:27 -0000 Hi! I'm using pipe masks for defining multiple queues per traffic flow, e.g. $cmd pipe 100 config mask all bw $webclient_upload_bandwidth queue $queue_size delay $client_rtt_delay $cmd pipe 200 config mask all bw $webclient_download_bandwidth queue $queue_size delay $client_rtt_delay $cmd add pipe 100 all from $client1_subnet to $server1_subnet in recv $in_if $cmd add pipe 200 all from $server1_subnet to $client1_subnet out xmit $in_if As you can see in the example above I'm defining a fixed delay value for all queues. Is it possible to define a delay distribution, e.g. min. 20ms, mean 50ms and max. 80ms for the pipe? I had a look at the ipfw howto (http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO), but couldn't find anything there nor via google. Thanks in advance for any help! Regards, Sebastian From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 20 15:57:06 2009 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 CF763106566C for ; Fri, 20 Mar 2009 15:57:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 946C88FC08 for ; Fri, 20 Mar 2009 15:57:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 872C673098; Fri, 20 Mar 2009 17:01:54 +0100 (CET) Date: Fri, 20 Mar 2009 17:01:54 +0100 From: Luigi Rizzo To: Sebastian Mellmann Message-ID: <20090320160154.GA92207@onelab2.iet.unipi.it> References: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw dummynet - delay distributions when using config masks 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, 20 Mar 2009 15:57:07 -0000 On Fri, Mar 20, 2009 at 04:53:26PM +0100, Sebastian Mellmann wrote: > Hi! > > > I'm using pipe masks for defining multiple queues per traffic flow, e.g. > > $cmd pipe 100 config mask all bw $webclient_upload_bandwidth queue $queue_size delay $client_rtt_delay > $cmd pipe 200 config mask all bw $webclient_download_bandwidth queue $queue_size delay $client_rtt_delay > > $cmd add pipe 100 all from $client1_subnet to $server1_subnet in recv $in_if > $cmd add pipe 200 all from $server1_subnet to $client1_subnet out xmit $in_if > > > As you can see in the example above I'm defining a fixed delay value for > all queues. > Is it possible to define a delay distribution, e.g. min. 20ms, mean 50ms > and max. 80ms for the pipe? we do have something that does the thing you are asking for, and should be committed soon to head (and easily backported to RELENG_7). Please be patient a couple of week, the code is already working and we only need to address some binary compatibility issue. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 20 23:47:23 2009 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 11EC6106564A for ; Fri, 20 Mar 2009 23:47:23 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 825D98FC16 for ; Fri, 20 Mar 2009 23:47:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n2KNkwTO011750; Sat, 21 Mar 2009 00:47:21 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n2KNkvQu011749; Sat, 21 Mar 2009 00:46:57 +0100 (CET) (envelope-from olli) Date: Sat, 21 Mar 2009 00:46:57 +0100 (CET) Message-Id: <200903202346.n2KNkvQu011749@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, dima_bsd@inbox.lv In-Reply-To: <200903192129.03360.dima_bsd@inbox.lv> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 21 Mar 2009 00:47:21 +0100 (CET) Cc: Subject: Re: keep-state rules inadequately handles big UDP ??packets?or?fragmented IP packets? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG, dima_bsd@inbox.lv List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 23:47:23 -0000 Dmitriy Demidov wrote: > Oliver Fromme wrote: > > I'm just curious ... Is it really worth the effort to add > > fragment reassembly to IPFW? What advantage does it have? > > > > It would be much easier to simply pass all fragments with > > offset > 1, and drop all fragments with offset 0 that are > > smaller than a certain reasonable minimum length. What > > would be the problem with this approach? > > Please wait... If I got it right (and dont missing something) then this rule: > ipfw add allow ip from any to me frag > have dissadvantage - I'm unabled to filter data by UDP/TCP ports. All IP > packets is just passing through firewall to me. No UDP/TCP filtering here? >From the ipfw(8) manual page: frag Matches packets that are fragments and not the first fragment of an IP datagram. That rule does _not_ pass the first fragment of a fragmented packet. So you can still filter by TCP and UDP ports. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch鋐tsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M黱- chen, HRB 125758, Gesch鋐tsf黨rer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 21 14:04:32 2009 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 27FDD1065670 for ; Sat, 21 Mar 2009 14:04:32 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from mail.qwe.net.ua (qwe.net.ua [80.245.118.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7DED08FC22 for ; Sat, 21 Mar 2009 14:04:31 +0000 (UTC) (envelope-from qwe@qwe.net.ua) Received: from localhost (localhost.qwe.net.ua [127.0.0.1]) by mail.qwe.net.ua (Postfix) with ESMTP id 90921CBD0 for ; Sat, 21 Mar 2009 16:04:30 +0200 (EET) Received: from mail.qwe.net.ua ([127.0.0.1]) by localhost (qwe.net.ua [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ggv7drUWJUP for ; Sat, 21 Mar 2009 16:04:27 +0200 (EET) Received: from [10.2.1.1] (unknown [10.2.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.qwe.net.ua (Postfix) with ESMTP id 64A2DC812 for ; Sat, 21 Mar 2009 16:04:27 +0200 (EET) Message-ID: <49C4F3EE.2080903@qwe.net.ua> Date: Sat, 21 Mar 2009 16:04:30 +0200 From: Eugene L Kovalenja User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <49C04CA3.1070100@qwe.net.ua> <49C35EB3.6040508@FreeBSD.org> In-Reply-To: <49C35EB3.6040508@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: FreeBSD 7.0: dummynet 99% cpu 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: Sat, 21 Mar 2009 14:04:32 -0000 Sergey Matveyhcuk 锌懈褕械褌: > Could you test an included patch? > > Eugene L Kovalenja wrote: >> >> Time in three days traffic via ipfw doesn't go. In top: >> 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% >> dummynet >> (this is example, not copy\paste) >> >> Also sw1: net increases from 5-10% to 30-35%... >> >> I am helped only by reboot. >> >> In what can consist the problem? >> > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" Hello. Thank you for this patch. After kernel patching trouble changes: Mar 21 13:58:45 taurus kernel: bge0: watchdog timeout -- resetting Mar 21 13:58:45 taurus kernel: bge0: link state changed to DOWN In top utility 99% cpu on irq bge0. Changing of network adapter (on board 2 adapters: bge0 && bge1) didn't decide problem. my /boot/loader.conf [root@taurus /usr/home/login]# cat /boot/loader.conf kern.ipc.maxpipekva=67108864 net.graph.maxalloc=2048 #vm.kmem_size_max="512M" #vm.kmem_size="512M" kern.maxusers="512" :( From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 21 17:14:43 2009 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 36E89106568B for ; Sat, 21 Mar 2009 17:14:43 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from sunner.semmy.ru (sunner.semmy.ru [195.54.209.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6368FC0C for ; Sat, 21 Mar 2009 17:14:41 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.76.79] (helo=[172.16.100.19]) by sunner.semmy.ru with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ll4mO-000HCA-Ns; Sat, 21 Mar 2009 20:14:40 +0300 Message-ID: <49C52060.6060504@FreeBSD.org> Date: Sat, 21 Mar 2009 20:14:08 +0300 From: Sergey Matveyhcuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eugene L Kovalenja References: <49C04CA3.1070100@qwe.net.ua> <49C35EB3.6040508@FreeBSD.org> <49C4F3EE.2080903@qwe.net.ua> In-Reply-To: <49C4F3EE.2080903@qwe.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: FreeBSD 7.0: dummynet 99% cpu 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: Sat, 21 Mar 2009 17:14:44 -0000 Well, I did not test the patch. Quick idea was to decrease hash buckets increasing of hash size. I did not dig deeper dummynet. Eugene L Kovalenja wrote: > Sergey Matveyhcuk 锌懈褕械褌: >> Could you test an included patch? >> >> Eugene L Kovalenja wrote: >>> >>> Time in three days traffic via ipfw doesn't go. In top: >>> 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% >>> dummynet >>> (this is example, not copy\paste) >>> >>> Also sw1: net increases from 5-10% to 30-35%... >>> >>> I am helped only by reboot. >>> >>> In what can consist the problem? >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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" > Hello. > > Thank you for this patch. > > After kernel patching trouble changes: > Mar 21 13:58:45 taurus kernel: bge0: watchdog timeout -- resetting > Mar 21 13:58:45 taurus kernel: bge0: link state changed to DOWN > > In top utility 99% cpu on irq bge0. > > Changing of network adapter (on board 2 adapters: bge0 && bge1) didn't > decide problem. > > my /boot/loader.conf > [root@taurus /usr/home/login]# cat /boot/loader.conf > kern.ipc.maxpipekva=67108864 > net.graph.maxalloc=2048 > > #vm.kmem_size_max="512M" > #vm.kmem_size="512M" > kern.maxusers="512" > > :(