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