From owner-freebsd-ipfw@FreeBSD.ORG Mon May 3 08:09:32 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4E7D16A4CE for ; Mon, 3 May 2004 08:09:32 -0700 (PDT) Received: from natsmtp00.rzone.de (natsmtp00.rzone.de [81.169.145.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0010643D2D for ; Mon, 3 May 2004 08:09:31 -0700 (PDT) (envelope-from andrea@ae4u.de) Received: from ae4u.de (mail.engel-kg.com [62.80.41.218]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i43F9Tpt028570; Mon, 3 May 2004 17:09:30 +0200 (MEST) Message-ID: <40967D45.3080708@ae4u.de> Date: Mon, 03 May 2004 17:11:33 +0000 From: "Andrea E." Organization: http://www.ae4u.de/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030903 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: Supote Leelasupphakorn References: <20040502051806.68324.qmail@web40602.mail.yahoo.com> In-Reply-To: <20040502051806.68324.qmail@web40602.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@FreeBSD.org Subject: Re: ipfw with NAT and ARP X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 15:09:33 -0000 hi, i have installed and configured freebsd 5.2.1 new. now i can do ping and all other network commands. at this moment I don't know, what the problem was. thanks for all your help Andrea Supote Leelasupphakorn wrote: > Hi Andrea E. > > From my understand if you'd like to ping from EXTERNAL ip > to EXTERNAL ip, the firewall is not involve because it will > reach each other directly. Could you confirm that you'd like > to "ping from EXTERNAL ip to EXTERNAL ip" so someone can find > out the solution ? > > Cheers, > pjn > > --- Supote Leelasupphakorn wrote: > Hi, > >>I am a newbie and my question is very easy perhaps. I work >>with >>FreeBSD >>5.2.1 >> >>I would like to configure a firewall with to interfaces (xl0 = >>LAN, xl1 >>= External) >> >>For NAT I have configured like discribed in the manualpage of >>natd: >> >>ipfw -f flush >>ipfw add divert natd all from any to any via xl1 >>ipfw add allow all from any to any >> >>-> all is fine. >> >>But, I wont so a simple firewall and for this reason, first I >>want to >>configure the ICMP-protocol: >> >>ip_ext => External IP-Address >> >>ipfw -f flush >>ipfw add divert natd all from any to any via xl1 >>ipfw add allow icmp from $ip_ext to any icmptypes 8 out via >>xl1 >>ipfw add allow icmp from any to $ip_ext icmptypes 0 in via >>xl1 >> >>-> It's not ok. With "ethereal" no pakets are going out (test >>from an >>other system, connected with a HUP.) >> >>When testing "ping" from external to external IP-Adress of my >>firewall, >>the ARP-request: to broadcast Who has xxx.xxx.xxx.xxx? Tell >>xxx.xxx.xxx.xxx fails >> >>-> seems to have a problem to let ARP through the firewall. >> >>Above -> "ipfw add allow all from any to any" let ARP through >>the >>firewall. So I think, thats the configuration of the rest of >>my >>computer >>(like kernel, rc.conf, etc. ist ok) >> >>And there are no ARP-protocol in /etc/protocols, so I don't >>know, what I >>can do now. >> >>There is a bug: >>After restarting system with above configuration of >>icmp-protocol no >>ping-request is going out. After a flush of all rules and >>configuring of >>"ipfw add allow all from any to any" ping-request get an >>answer. >>Very interesting is to flush all rules und to configure the >>firewall >>like the first configuring (to allow special rules for >>icmp-protocol -> >>all works very fine. ping-request get an answer. Whenn >>restarting system >>the ping-request get no answer again, I mean, the ping-request >>is not >>send out. >> >>Can anybody help me? Hope to get an answer. >> >>I hope you can understand me, my English isn't very well. >> >>Greatings from Berlin, >> >> Andrea E. >> >> >> > > ________________________________________________________________________ > >>Yahoo! Messenger - Communicate instantly..."Ping" >>your friends today! Download Messenger Now >>http://uk.messenger.yahoo.com/download/index.html > > > ________________________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > From owner-freebsd-ipfw@FreeBSD.ORG Mon May 3 11:02:22 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E9DE16A4CE for ; Mon, 3 May 2004 11:02:22 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3F543D31 for ; Mon, 3 May 2004 11:02:22 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i43I2L5G028895 for ; Mon, 3 May 2004 11:02:22 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i43I2L1e028889 for ipfw@freebsd.org; Mon, 3 May 2004 11:02:21 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 May 2004 11:02:21 -0700 (PDT) Message-Id: <200405031802.i43I2L1e028889@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:02:22 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp o [2004/03/03] misc/63724 ipfw IPFW2 Queues dont t work o [2004/03/13] kern/64240 ipfw IPFW tee terminates rule processing 5 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp o [2004/01/12] kern/61259 ipfw [patch] make "ipfw tee" work as intended o [2004/02/09] kern/62598 ipfw no logging on ipfw loadable module o [2004/03/08] kern/63961 ipfw ipfw2 uid matching doesn't work correctly 13 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed May 5 07:13:10 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9212D16A4CE for ; Wed, 5 May 2004 07:13:10 -0700 (PDT) Received: from hugle.vkt.lt (hugle.vkt.lt [213.252.192.162]) by mx1.FreeBSD.org (Postfix) with SMTP id 32E9543D46 for ; Wed, 5 May 2004 07:13:09 -0700 (PDT) (envelope-from hugle@vkt.lt) Received: (qmail 52407 invoked by uid 0); 5 May 2004 15:15:52 -0000 Received: from user-1-8.vkt.lan (HELO vkt-dell) (192.168.1.8) by router.vkt.lan with SMTP; 5 May 2004 15:15:52 -0000 Date: Wed, 5 May 2004 17:13:07 +0300 From: hugle X-Mailer: The Bat! (v2.01) X-Priority: 3 (Normal) Message-ID: <104341060709.20040505171307@vkt.lt> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hugle List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 14:13:10 -0000 Hello all. I get such messages in dmesg: ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet what is causing such messages ? google doesn't say anything.. and one more thing.. i've realised, that pipes doesn't give my banthiwith I should get instead of 100kbits i get ~70... insted of 156 i get ~100 and so on.. anyone have a clue whete to search? -- Best regards,Hugle From owner-freebsd-ipfw@FreeBSD.ORG Wed May 5 08:46:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3000E16A4CE for ; Wed, 5 May 2004 08:46:43 -0700 (PDT) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 671C143D48 for ; Wed, 5 May 2004 08:46:42 -0700 (PDT) (envelope-from oleg@rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.12.11/8.12.11) with ESMTP id i45FkeJZ009877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2004 19:46:40 +0400 (MSD) (envelope-from oleg@rinet.ru) Received: from localhost (oleg@localhost)i45FkeRO009874; Wed, 5 May 2004 19:46:40 +0400 (MSD) (envelope-from oleg@rinet.ru) Date: Wed, 5 May 2004 19:46:40 +0400 (MSD) From: Oleg Bulyzhin To: hugle In-Reply-To: <104341060709.20040505171307@vkt.lt> Message-ID: <20040505194451.V9766@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 15:46:43 -0000 On Wed, 5 May 2004, hugle wrote: > Hello all. > I get such messages in dmesg: > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > ipfw: ouch!, skip past end of rules, denying packet > > what is causing such messages ? > google doesn't say anything.. > and one more thing.. > i've realised, that pipes doesn't give my banthiwith I should get > > instead of 100kbits i get ~70... > insted of 156 i get ~100 > and so on.. > anyone have a clue whete to search? > What is your value of net.inet.ip.fw.one_pass sysctl variable? -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-ipfw@FreeBSD.ORG Thu May 6 08:15:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CF6B16A4CF for ; Thu, 6 May 2004 08:15:30 -0700 (PDT) Received: from calypso.bi.lt (calypso.bi.lt [213.226.153.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90BC443D3F for ; Thu, 6 May 2004 08:15:29 -0700 (PDT) (envelope-from hugle@vkt.lt) Received: by calypso.bi.lt (Postfix, from userid 506) id 85930598F43; Thu, 6 May 2004 18:15:27 +0300 (EEST) X-Original-To: freebsd-ipfw@freebsd.org Received: from vkt-dell (lan1.vkt.lt [213.226.136.201]) by calypso.bi.lt (Postfix) with ESMTP id C1517598BAC for ; Thu, 6 May 2004 18:15:26 +0300 (EEST) Date: Thu, 6 May 2004 10:36:15 +0300 From: hugle X-Mailer: The Bat! (v2.01) X-Priority: 3 (Normal) Message-ID: <158403649347.20040506103615@vkt.lt> To: freebsd-ipfw@freebsd.org In-Reply-To: <20040505194451.V9766@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hugle List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 15:15:30 -0000 OB> On Wed, 5 May 2004, hugle wrote: >> Hello all. >> I get such messages in dmesg: >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> ipfw: ouch!, skip past end of rules, denying packet >> >> what is causing such messages ? >> google doesn't say anything.. >> and one more thing.. >> i've realised, that pipes doesn't give my banthiwith I should get >> >> instead of 100kbits i get ~70... >> insted of 156 i get ~100 >> and so on.. >> anyone have a clue whete to search? >> OB> What is your value of net.inet.ip.fw.one_pass sysctl variable? perl# sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 From owner-freebsd-ipfw@FreeBSD.ORG Thu May 6 14:35:15 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B9616A4CE for ; Thu, 6 May 2004 14:35:14 -0700 (PDT) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC57E43D2F for ; Thu, 6 May 2004 14:35:13 -0700 (PDT) (envelope-from oleg@rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.12.11/8.12.11) with ESMTP id i46LZBOc001856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 01:35:11 +0400 (MSD) (envelope-from oleg@rinet.ru) Received: from localhost (oleg@localhost)i46LZBk1001853; Fri, 7 May 2004 01:35:11 +0400 (MSD) (envelope-from oleg@rinet.ru) Date: Fri, 7 May 2004 01:35:11 +0400 (MSD) From: Oleg Bulyzhin To: hugle In-Reply-To: <158403649347.20040506103615@vkt.lt> Message-ID: <20040507013009.H1824@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <158403649347.20040506103615@vkt.lt> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1378115432-1083879311=:1824" cc: freebsd-ipfw@freebsd.org Subject: Re[2]: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 21:35:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1378115432-1083879311=:1824 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 May 2004, hugle wrote: > OB> On Wed, 5 May 2004, hugle wrote: > > >> Hello all. > >> I get such messages in dmesg: > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> ipfw: ouch!, skip past end of rules, denying packet > >> > >> what is causing such messages ? > >> google doesn't say anything.. > >> and one more thing.. > >> i've realised, that pipes doesn't give my banthiwith I should get > >> > >> instead of 100kbits i get ~70... > >> insted of 156 i get ~100 > >> and so on.. > >> anyone have a clue whete to search? > >> > > OB> What is your value of net.inet.ip.fw.one_pass sysctl variable? > > > perl# sysctl net.inet.ip.fw.one_pass > net.inet.ip.fw.one_pass: 0 i see. There is a little bug (i'll PR it as soon i'll get enough time), you can try attached patch(built on RELENG_4). > > > _______________________________________________ > 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" > -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --0-1378115432-1083879311=:1824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ipfw-skippast.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20040507013511.S1824@lath.rinet.ru> Content-Description: ipfw patch Content-Disposition: attachment; filename="ipfw-skippast.patch" LS0tIHN5cy9uZXRpbmV0L2lwX2R1bW15bmV0LmN+CVR1ZSBEZWMgMzAgMTU6 Mjg6MDkgMjAwMw0KKysrIHN5cy9uZXRpbmV0L2lwX2R1bW15bmV0LmMJV2Vk IE1heSAgNSAyMTo0MTowOSAyMDA0DQpAQCAtMTM3OCw3ICsxMzc4LDYgQEAN CiB9DQogDQogDQotZXh0ZXJuIHN0cnVjdCBpcF9mdyAqaXBfZndfZGVmYXVs dF9ydWxlIDsNCiBzdGF0aWMgdm9pZA0KIGRuX3J1bGVfZGVsZXRlX2ZzKHN0 cnVjdCBkbl9mbG93X3NldCAqZnMsIHZvaWQgKnIpDQogew0KQEAgLTEzOTAs NyArMTM4OSw3IEBADQogCWZvciAocSA9IGZzLT5ycVtpXSA7IHEgOyBxID0g cS0+bmV4dCApDQogCSAgICBmb3IgKHBrdCA9IHEtPmhlYWQgOyBwa3QgOyBw a3QgPSBETl9ORVhUKHBrdCkgKQ0KIAkJaWYgKHBrdC0+cnVsZSA9PSByKQ0K LQkJICAgIHBrdC0+cnVsZSA9IGlwX2Z3X2RlZmF1bHRfcnVsZSA7DQorCQkg ICAgcGt0LT5ydWxlID0gbG9va3VwX25leHRfcnVsZShwa3QtPnJ1bGUpOw0K IH0NCiAvKg0KICAqIHdoZW4gYSBmaXJld2FsbCBydWxlIGlzIGRlbGV0ZWQs IHNjYW4gYWxsIHF1ZXVlcyBhbmQgcmVtb3ZlIHRoZSBmbG93LWlkDQpAQCAt MTQxNSw3ICsxNDE0LDcgQEANCiAJZG5fcnVsZV9kZWxldGVfZnMoZnMsIHIp Ow0KIAlmb3IgKHBrdCA9IHAtPmhlYWQgOyBwa3QgOyBwa3QgPSBETl9ORVhU KHBrdCkgKQ0KIAkgICAgaWYgKHBrdC0+cnVsZSA9PSByKQ0KLQkJcGt0LT5y dWxlID0gaXBfZndfZGVmYXVsdF9ydWxlIDsNCisJCXBrdC0+cnVsZSA9IGxv b2t1cF9uZXh0X3J1bGUocGt0LT5ydWxlKTsNCiAgICAgfQ0KIH0NCiANCi0t LSBzeXMvbmV0aW5ldC9pcF9mdy5jfglNb24gSmFuIDIwIDA1OjIzOjA3IDIw MDMNCisrKyBzeXMvbmV0aW5ldC9pcF9mdy5jCVdlZCBNYXkgIDUgMjE6NTM6 MDYgMjAwNA0KQEAgLTEwMjMsOSArMTAyMyw3IEBADQogICogQmFja3dhcmQg anVtcHMgYXJlIG5vdCBhbGxvd2VkLCBzbyBzdGFydCBsb29raW5nIGZyb20g dGhlIG5leHQNCiAgKiBydWxlLi4uDQogICovIA0KLXN0YXRpYyBzdHJ1Y3Qg aXBfZncgKiBsb29rdXBfbmV4dF9ydWxlKHN0cnVjdCBpcF9mdyAqbWUpOw0K LQ0KLXN0YXRpYyBzdHJ1Y3QgaXBfZncgKg0KK3N0cnVjdCBpcF9mdyAqDQog bG9va3VwX25leHRfcnVsZShzdHJ1Y3QgaXBfZncgKm1lKQ0KIHsNCiAgICAg c3RydWN0IGlwX2Z3ICpydWxlIDsNCkBAIC0yMDY2LDE2ICsyMDY0LDYgQEAN CiAJcmV0dXJuIChlcnJvcik7DQogfQ0KIA0KLS8qKg0KLSAqIGR1bW15bmV0 IG5lZWRzIGEgcmVmZXJlbmNlIHRvIHRoZSBkZWZhdWx0IHJ1bGUsIGJlY2F1 c2UgcnVsZXMgY2FuDQotICogYmUgZGVsZXRlZCB3aGlsZSBwYWNrZXRzIGhv bGQgYSByZWZlcmVuY2UgdG8gdGhlbSAoZS5nLiB0byByZXN1bWUNCi0gKiBw cm9jZXNzaW5nIGF0IHRoZSBuZXh0IHJ1bGUpLiBXaGVuIHRoaXMgaGFwcGVu cywgZHVtbXluZXQgY2hhbmdlcw0KLSAqIHRoZSByZWZlcmVuY2UgdG8gdGhl IGRlZmF1bHQgcnVsZSAocHJvYmFibHkgaXQgY291bGQgd2VsbCBiZSBhDQot ICogTlVMTCBwb2ludGVyLCBidXQgdGhpcyB3YXkgd2UgZG8gbm90IG5lZWQg dG8gY2hlY2sgZm9yIHRoZSBzcGVjaWFsDQotICogY2FzZSwgcGx1cyBoZXJl IGhlIGhhdmUgaW5mbyBvbiB0aGUgZGVmYXVsdCBiZWhhdmlvdXIuDQotICov DQotc3RydWN0IGlwX2Z3ICppcF9md19kZWZhdWx0X3J1bGUgOw0KLQ0KIHZv aWQNCiBpcF9md19pbml0KHZvaWQpDQogew0KQEAgLTIwOTgsNyArMjA4Niw2 IEBADQogCSAgICBhZGRfZW50cnkoJmlwX2Z3X2NoYWluX2hlYWQsICZkZWZh dWx0X3J1bGUpKQ0KIAkJcGFuaWMoImlwX2Z3X2luaXQiKTsNCiANCi0JaXBf ZndfZGVmYXVsdF9ydWxlID0gTElTVF9GSVJTVCgmaXBfZndfY2hhaW5faGVh ZCkgOw0KIAlwcmludGYoIklQIHBhY2tldCBmaWx0ZXJpbmcgaW5pdGlhbGl6 ZWQsICINCiAjaWZkZWYgSVBESVZFUlQNCiAJCSJkaXZlcnQgZW5hYmxlZCwg Ig0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3Lmh+CVR1ZSBKdWwgIDkgMTM6MTE6 NDIgMjAwMg0KKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJV2VkIE1heSAgNSAy MTo0NzoyMSAyMDA0DQpAQCAtMzYwLDYgKzM2MCw3IEBADQogc3RydWN0IHNv Y2tvcHQ7DQogc3RydWN0IGRuX2Zsb3dfc2V0Ow0KIHZvaWQgZmx1c2hfcGlw ZV9wdHJzKHN0cnVjdCBkbl9mbG93X3NldCAqbWF0Y2gpOyAvKiB1c2VkIGJ5 IGR1bW15bmV0ICovDQorc3RydWN0IGlwX2Z3ICogbG9va3VwX25leHRfcnVs ZShzdHJ1Y3QgaXBfZncgKm1lKTsNCiANCiB0eXBlZGVmIGludCBpcF9md19j aGtfdCAoc3RydWN0IGlwX2Z3X2FyZ3MgKmFyZ3MpOw0KIHR5cGVkZWYgaW50 IGlwX2Z3X2N0bF90IChzdHJ1Y3Qgc29ja29wdCAqKTsNCi0tLSBzeXMvbmV0 aW5ldC9pcF9mdzIuY34JRnJpIEFwciAgMiAyMToxNTo0NCAyMDA0DQorKysg c3lzL25ldGluZXQvaXBfZncyLmMJV2VkIE1heSAgNSAyMTo0NDo1NSAyMDA0 DQpAQCAtMTIyMSw3ICsxMjIxLDcgQEANCiAgKiBwb2ludGVycyBhcmUgZmx1 c2hlZCBzbyB3ZSBhcmUgYWx3YXlzIGNvcnJlY3QuDQogICovDQogDQotc3Rh dGljIHN0cnVjdCBpcF9mdyAqDQorc3RydWN0IGlwX2Z3ICoNCiBsb29rdXBf bmV4dF9ydWxlKHN0cnVjdCBpcF9mdyAqbWUpDQogew0KIAlzdHJ1Y3QgaXBf ZncgKnJ1bGUgPSBOVUxMOw0KQEAgLTI3MjEsMTUgKzI3MjEsNiBAQA0KIAly ZXR1cm4gKGVycm9yKTsNCiB9DQogDQotLyoqDQotICogZHVtbXluZXQgbmVl ZHMgYSByZWZlcmVuY2UgdG8gdGhlIGRlZmF1bHQgcnVsZSwgYmVjYXVzZSBy dWxlcyBjYW4gYmUNCi0gKiBkZWxldGVkIHdoaWxlIHBhY2tldHMgaG9sZCBh IHJlZmVyZW5jZSB0byB0aGVtLiBXaGVuIHRoaXMgaGFwcGVucywNCi0gKiBk dW1teW5ldCBjaGFuZ2VzIHRoZSByZWZlcmVuY2UgdG8gdGhlIGRlZmF1bHQg cnVsZSAoaXQgY291bGQgd2VsbCBiZSBhDQotICogTlVMTCBwb2ludGVyLCBi dXQgdGhpcyB3YXkgd2UgZG8gbm90IG5lZWQgdG8gY2hlY2sgZm9yIHRoZSBz cGVjaWFsDQotICogY2FzZSwgcGx1cyBoZXJlIGhlIGhhdmUgaW5mbyBvbiB0 aGUgZGVmYXVsdCBiZWhhdmlvdXIpLg0KLSAqLw0KLXN0cnVjdCBpcF9mdyAq aXBfZndfZGVmYXVsdF9ydWxlOw0KLQ0KIC8qDQogICogVGhpcyBwcm9jZWR1 cmUgaXMgb25seSB1c2VkIHRvIGhhbmRsZSBrZWVwYWxpdmVzLiBJdCBpcyBp bnZva2VkDQogICogZXZlcnkgZHluX2tlZXBhbGl2ZV9wZXJpb2QNCkBAIC0y NzkzLDcgKzI3ODQsNiBAQA0KIA0KIAlhZGRfcnVsZSgmbGF5ZXIzX2NoYWlu LCAmZGVmYXVsdF9ydWxlKTsNCiANCi0JaXBfZndfZGVmYXVsdF9ydWxlID0g bGF5ZXIzX2NoYWluOw0KIAlwcmludGYoImlwZncyIGluaXRpYWxpemVkLCBk aXZlcnQgJXMsICINCiAJCSJydWxlLWJhc2VkIGZvcndhcmRpbmcgZW5hYmxl ZCwgZGVmYXVsdCB0byAlcywgbG9nZ2luZyAiLA0KICNpZmRlZiBJUERJVkVS VA0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3Mi5ofglUaHUgSnVsIDE3IDEwOjAz OjM5IDIwMDMNCisrKyBzeXMvbmV0aW5ldC9pcF9mdzIuaAlXZWQgTWF5ICA1 IDIxOjQ0OjEwIDIwMDQNCkBAIC00MTMsNiArNDEzLDcgQEANCiBzdHJ1Y3Qg ZG5fZmxvd19zZXQ7DQogDQogdm9pZCBmbHVzaF9waXBlX3B0cnMoc3RydWN0 IGRuX2Zsb3dfc2V0ICptYXRjaCk7IC8qIHVzZWQgYnkgZHVtbXluZXQgKi8N CitzdHJ1Y3QgaXBfZncgKiBsb29rdXBfbmV4dF9ydWxlKHN0cnVjdCBpcF9m dyAqbWUpOw0KIA0KIHR5cGVkZWYgaW50IGlwX2Z3X2Noa190IChzdHJ1Y3Qg aXBfZndfYXJncyAqYXJncyk7DQogdHlwZWRlZiBpbnQgaXBfZndfY3RsX3Qg KHN0cnVjdCBzb2Nrb3B0ICopOw0K --0-1378115432-1083879311=:1824-- From owner-freebsd-ipfw@FreeBSD.ORG Thu May 6 15:38:16 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF99016A4CE for ; Thu, 6 May 2004 15:38:16 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0290F43D39 for ; Thu, 6 May 2004 15:38:16 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i46McFgd076644; Thu, 6 May 2004 15:38:15 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i46McFuf076643; Thu, 6 May 2004 15:38:15 -0700 (PDT) (envelope-from rizzo) Date: Thu, 6 May 2004 15:38:15 -0700 From: Luigi Rizzo To: Oleg Bulyzhin Message-ID: <20040506153815.A75812@xorpc.icir.org> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <158403649347.20040506103615@vkt.lt> <20040507013009.H1824@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040507013009.H1824@lath.rinet.ru>; from oleg@rinet.ru on Fri, May 07, 2004 at 01:35:11AM +0400 cc: hugle cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:38:16 -0000 On Fri, May 07, 2004 at 01:35:11AM +0400, Oleg Bulyzhin wrote: ... > i see. > There is a little bug (i'll PR it as soon i'll get enough time), you can > try attached patch(built on RELENG_4). very interesting that you found out what the bug was -- i couldn't realize it myself. Thanks! However, i believe the fix is incorrect and in principle can still trigger the problem (which is innocuous). The bug your patch addresses is the following: when a packet is stored in a pipe, dummynet keeps a pointer to the matching rule so if one_pass=0 it can restart processing from the following one. if the matching rule goes away while a packet is queued, my intention was to use the default rule as the next one, but i mistakenly used the default rule as the _matching_ one. Your patch replaces the matching rule with the next one, which however might still end up being the default rule; so it does not fix the proble, plus, it might completely subvert the packet's flow. I believe a proper fix is right before the main loop in ipfw_chk(), check if we enter with a NULL rule pointer and use the default rule instead. Alternatively, if we believe that when a rule goes away we should also drop queued packets because the resulting behaviour would be unpredictable or unsafe, then what happens now is basically correct (not by design, just pure luck), and we just need to remove the 'ouch...' message 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" > > > > -- > Oleg. > > ================================================================ > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > ================================================================ Content-Description: ipfw patch > --- sys/netinet/ip_dummynet.c~ Tue Dec 30 15:28:09 2003 > +++ sys/netinet/ip_dummynet.c Wed May 5 21:41:09 2004 > @@ -1378,7 +1378,6 @@ > } > > > -extern struct ip_fw *ip_fw_default_rule ; > static void > dn_rule_delete_fs(struct dn_flow_set *fs, void *r) > { > @@ -1390,7 +1389,7 @@ > for (q = fs->rq[i] ; q ; q = q->next ) > for (pkt = q->head ; pkt ; pkt = DN_NEXT(pkt) ) > if (pkt->rule == r) > - pkt->rule = ip_fw_default_rule ; > + pkt->rule = lookup_next_rule(pkt->rule); > } > /* > * when a firewall rule is deleted, scan all queues and remove the flow-id > @@ -1415,7 +1414,7 @@ > dn_rule_delete_fs(fs, r); > for (pkt = p->head ; pkt ; pkt = DN_NEXT(pkt) ) > if (pkt->rule == r) > - pkt->rule = ip_fw_default_rule ; > + pkt->rule = lookup_next_rule(pkt->rule); > } > } > > --- sys/netinet/ip_fw.c~ Mon Jan 20 05:23:07 2003 > +++ sys/netinet/ip_fw.c Wed May 5 21:53:06 2004 > @@ -1023,9 +1023,7 @@ > * Backward jumps are not allowed, so start looking from the next > * rule... > */ > -static struct ip_fw * lookup_next_rule(struct ip_fw *me); > - > -static struct ip_fw * > +struct ip_fw * > lookup_next_rule(struct ip_fw *me) > { > struct ip_fw *rule ; > @@ -2066,16 +2064,6 @@ > return (error); > } > > -/** > - * dummynet needs a reference to the default rule, because rules can > - * be deleted while packets hold a reference to them (e.g. to resume > - * processing at the next rule). When this happens, dummynet changes > - * the reference to the default rule (probably it could well be a > - * NULL pointer, but this way we do not need to check for the special > - * case, plus here he have info on the default behaviour. > - */ > -struct ip_fw *ip_fw_default_rule ; > - > void > ip_fw_init(void) > { > @@ -2098,7 +2086,6 @@ > add_entry(&ip_fw_chain_head, &default_rule)) > panic("ip_fw_init"); > > - ip_fw_default_rule = LIST_FIRST(&ip_fw_chain_head) ; > printf("IP packet filtering initialized, " > #ifdef IPDIVERT > "divert enabled, " > --- sys/netinet/ip_fw.h~ Tue Jul 9 13:11:42 2002 > +++ sys/netinet/ip_fw.h Wed May 5 21:47:21 2004 > @@ -360,6 +360,7 @@ > struct sockopt; > struct dn_flow_set; > void flush_pipe_ptrs(struct dn_flow_set *match); /* used by dummynet */ > +struct ip_fw * lookup_next_rule(struct ip_fw *me); > > typedef int ip_fw_chk_t (struct ip_fw_args *args); > typedef int ip_fw_ctl_t (struct sockopt *); > --- sys/netinet/ip_fw2.c~ Fri Apr 2 21:15:44 2004 > +++ sys/netinet/ip_fw2.c Wed May 5 21:44:55 2004 > @@ -1221,7 +1221,7 @@ > * pointers are flushed so we are always correct. > */ > > -static struct ip_fw * > +struct ip_fw * > lookup_next_rule(struct ip_fw *me) > { > struct ip_fw *rule = NULL; > @@ -2721,15 +2721,6 @@ > return (error); > } > > -/** > - * dummynet needs a reference to the default rule, because rules can be > - * deleted while packets hold a reference to them. When this happens, > - * dummynet changes the reference to the default rule (it could well be a > - * NULL pointer, but this way we do not need to check for the special > - * case, plus here he have info on the default behaviour). > - */ > -struct ip_fw *ip_fw_default_rule; > - > /* > * This procedure is only used to handle keepalives. It is invoked > * every dyn_keepalive_period > @@ -2793,7 +2784,6 @@ > > add_rule(&layer3_chain, &default_rule); > > - ip_fw_default_rule = layer3_chain; > printf("ipfw2 initialized, divert %s, " > "rule-based forwarding enabled, default to %s, logging ", > #ifdef IPDIVERT > --- sys/netinet/ip_fw2.h~ Thu Jul 17 10:03:39 2003 > +++ sys/netinet/ip_fw2.h Wed May 5 21:44:10 2004 > @@ -413,6 +413,7 @@ > struct dn_flow_set; > > void flush_pipe_ptrs(struct dn_flow_set *match); /* used by dummynet */ > +struct ip_fw * lookup_next_rule(struct ip_fw *me); > > typedef int ip_fw_chk_t (struct ip_fw_args *args); > typedef int ip_fw_ctl_t (struct sockopt *); > _______________________________________________ > 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 Fri May 7 02:17:24 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C653416A4CE for ; Fri, 7 May 2004 02:17:24 -0700 (PDT) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049FD43D31 for ; Fri, 7 May 2004 02:17:24 -0700 (PDT) (envelope-from oleg@rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.12.11/8.12.11) with ESMTP id i479HMra004925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 13:17:22 +0400 (MSD) (envelope-from oleg@rinet.ru) Received: from localhost (oleg@localhost)i479HMbC004922; Fri, 7 May 2004 13:17:22 +0400 (MSD) (envelope-from oleg@rinet.ru) Date: Fri, 7 May 2004 13:17:22 +0400 (MSD) From: Oleg Bulyzhin To: Luigi Rizzo In-Reply-To: <20040506153815.A75812@xorpc.icir.org> Message-ID: <20040507111750.Q3806@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040507013009.H1824@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 09:17:25 -0000 On Thu, 6 May 2004, Luigi Rizzo wrote: > On Fri, May 07, 2004 at 01:35:11AM +0400, Oleg Bulyzhin wrote: > ... > > i see. > > There is a little bug (i'll PR it as soon i'll get enough time), you can > > try attached patch(built on RELENG_4). > > very interesting that you found out what the bug was -- i > couldn't realize it myself. Thanks! > > However, i believe the fix is incorrect and in principle can > still trigger the problem (which is innocuous). > > The bug your patch addresses is the following: > when a packet is stored in a pipe, dummynet keeps a pointer > to the matching rule so if one_pass=0 it can restart processing > from the following one. > > if the matching rule goes away while a packet is queued, > my intention was to use the default rule as the next one, > but i mistakenly used the default rule as the _matching_ one. > > Your patch replaces the matching rule with the next one, > which however might still end up being the default rule; > so it does not fix the proble, plus, it might completely > subvert the packet's flow. I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for 'next rule', perhaps we should add it? To my mind problem is not log pollution with 'skip past' messages but dropping packets which _should_ be further processed. If we have no default_to_accept option in kernel and our next rule is default rule - packed should be dropped. If we are here (ip_fw2.c:1452): ---------------- | if (fw_one_pass) | return 0; | | f = args->rule->next_rule; <--- if (f == NULL) f = lookup_next_rule(args->rule); it means we got a packet which passed all rules up to pipe/queue rule and which was not dropped inside dummynet (i.e. packet already passed rule which was deleted). Why we should just drop such 'die hard' packet? ;)) > > I believe a proper fix is right before the main loop in > ipfw_chk(), check if we enter with a NULL rule pointer and use the > default rule instead. Hmm... consider following ruleset: net.inet.ip.fw.one_pass=0 ipfw pipe 1 config bw 1Mbit/s queue 8Kbytes 10 pipe 1 ip from any to 10.0.0.2 out 20 count ip from any to 10.0.0.2 out 65535 allow ip from any to any i.e. we are limiting user's bandwidth and want to know how much was downloaded through traffic shaper. Then user pay us for 10Mbit/s bandwidth: ipfw pipe 2 config bw 10Mbit/s queue 16Kbytes ipfw set disable 30 ipfw add 10 set 30 pipe 2 ip from any to 10.0.0.2 out ipfw set swap 30 0 #### NB! #### ipfw delete set 30 There are 2 cases: 1) if we delete temporary set 30 as fast as possible: With current code up to 8Kbytes data will be dropped. With your suggestion default rule will be used (packets will be passed in our case) but rule 20 will not catch em. 2) if we delete temporary set 30 after 5 seconds (i.e. when queue became empty): packets will be passed & counted by rule 20 > > Alternatively, if we believe that when a rule goes away > we should also drop queued packets because the resulting > behaviour would be unpredictable or unsafe, then what happens > now is basically correct (not by design, just pure luck), > and we just need to remove the 'ouch...' message Well, i think packets should not be dropped until we delete corresponding pipe or queue. > > cheers > luigi > -- SY, Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-ipfw@FreeBSD.ORG Fri May 7 02:42:07 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A6A016A4CE for ; Fri, 7 May 2004 02:42:07 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467F143D53 for ; Fri, 7 May 2004 02:42:07 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i479g7gd061850; Fri, 7 May 2004 02:42:07 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i479g754061849; Fri, 7 May 2004 02:42:07 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 May 2004 02:42:06 -0700 From: Luigi Rizzo To: Oleg Bulyzhin Message-ID: <20040507024206.B61144@xorpc.icir.org> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040507013009.H1824@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> <20040507111750.Q3806@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040507111750.Q3806@lath.rinet.ru>; from oleg@rinet.ru on Fri, May 07, 2004 at 01:17:22PM +0400 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 09:42:07 -0000 On Fri, May 07, 2004 at 01:17:22PM +0400, Oleg Bulyzhin wrote: ... > > Your patch replaces the matching rule with the next one, > > which however might still end up being the default rule; > > so it does not fix the proble, plus, it might completely > > subvert the packet's flow. > > I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for > 'next rule', perhaps we should add it? the problem is that there is a race here -- you start processing the packet, suspend, change the ruleset, then if one_pass=0 restart. When you restart, the ruleset might have little or nothing in common with the previous one, so there isn't really any assumption you can make that doesn't open holes in your firewall. So i really believe the only sensible choice in the above case is either drop the packet, or restart its processing from the beginning (but that might have annoying side effects). Dropping a packet (or a few) during a reconfiguration is not dramatic, it might have got lost anyways -- and note, this case is very different from reconfiguring a pipe's bandwidth, where you _know_ what to do with the packet (and still you cannot guarantee if it will come out at the desired rate). cheers luigii From owner-freebsd-ipfw@FreeBSD.ORG Fri May 7 04:19:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BAC816A4CE for ; Fri, 7 May 2004 04:19:09 -0700 (PDT) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C86B443D58 for ; Fri, 7 May 2004 04:19:08 -0700 (PDT) (envelope-from oleg@rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.12.11/8.12.11) with ESMTP id i47BJ7Ts005490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 15:19:07 +0400 (MSD) (envelope-from oleg@rinet.ru) Received: from localhost (oleg@localhost)i47BJ6MU005487; Fri, 7 May 2004 15:19:07 +0400 (MSD) (envelope-from oleg@rinet.ru) Date: Fri, 7 May 2004 15:19:06 +0400 (MSD) From: Oleg Bulyzhin To: Luigi Rizzo In-Reply-To: <20040507024206.B61144@xorpc.icir.org> Message-ID: <20040507150212.P5201@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> <20040507024206.B61144@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 11:19:09 -0000 On Fri, 7 May 2004, Luigi Rizzo wrote: > On Fri, May 07, 2004 at 01:17:22PM +0400, Oleg Bulyzhin wrote: > ... > > > Your patch replaces the matching rule with the next one, > > > which however might still end up being the default rule; > > > so it does not fix the proble, plus, it might completely > > > subvert the packet's flow. > > > > I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for > > 'next rule', perhaps we should add it? > > the problem is that there is a race here -- you start processing > the packet, suspend, change the ruleset, then if one_pass=0 restart. > When you restart, > the ruleset might have little or nothing in common with the previous > one, so there isn't really any assumption you can make that doesn't > open holes in your firewall. > So i really believe the only sensible choice in the above case > is either drop the packet, or restart its processing from the > beginning (but that might have annoying side effects). > > Dropping a packet (or a few) during a reconfiguration is not dramatic, > it might have got lost anyways -- and note, this case is very > different from reconfiguring a pipe's bandwidth, where you _know_ > what to do with the packet (and still you cannot guarantee > if it will come out at the desired rate). You have almost convinced me. Perhaps it would be better to apply default policy to such packets. Thanks for explanation! > > cheers > luigii > P.S. about your suggestion how to fix it: maybe instead of special check in ipfw_chk() would be better to change lookup_next_rule() behaviour in order to lookup_next_rule(default_rule) == default_rule? (anyway this function is not used for traversing list of rules); -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-ipfw@FreeBSD.ORG Sat May 8 19:08:15 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC36116A4CE for ; Sat, 8 May 2004 19:08:15 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6352B43D1F for ; Sat, 8 May 2004 19:08:15 -0700 (PDT) (envelope-from louie@transsys.com) Received: from whizzo.transsys.com (localhost [127.0.0.1]) by whizzo.transsys.com (Postfix) with ESMTP id 61BB120F78; Sat, 8 May 2004 22:08:14 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Oleg Bulyzhin Organization: Serendipity Scheduling & Management X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> <20040507024206.B61144@xorpc.icir.org> <20040507150212.P5201@lath.rinet.ru> In-reply-to: Your message of "Fri, 07 May 2004 15:19:06 +0400." <20040507150212.P5201@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 22:08:14 -0400 Sender: louie@transsys.com Message-Id: <20040509020814.61BB120F78@whizzo.transsys.com> cc: Luigi Rizzo cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 02:08:15 -0000 Not to hijack the thread here, but if you're looking at this code, it would be nice if the logic that the ipfw "queue" command used was similar to "divert"; where processing picks up at the next higher rule number rather than the next rule (which might be numbered the same.) I'd like to have a bunch of queue commands in a row (perhaps with less specific matching criteria in successive rules) and know that if they're all numbered the same, only the first one will match. louie