From owner-cvs-all@FreeBSD.ORG Wed Jul 16 00:09:17 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83DFC37B401; Wed, 16 Jul 2003 00:09:17 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3CF543F75; Wed, 16 Jul 2003 00:09:16 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h6G79EkN002594; Wed, 16 Jul 2003 00:09:14 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h6G79ERt002593; Wed, 16 Jul 2003 00:09:14 -0700 (PDT) (envelope-from rizzo) Date: Wed, 16 Jul 2003 00:09:14 -0700 From: Luigi Rizzo To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Message-ID: <20030716000913.A1936@xorpc.icir.org> References: <200307152307.h6FN7YcT018837@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@des.no on Wed, Jul 16, 2003 at 09:04:49AM +0200 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw.h ip_fw2.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 07:09:17 -0000 On Wed, Jul 16, 2003 at 09:04:49AM +0200, Dag-Erling Smørgrav wrote: > Luigi Rizzo writes: > > This implement a flexible form of "persistent rules" which you might > > want to have available even after an "ipfw flush". > > Note that this change does not violate POLA, because you could not > > use set 31 in a ruleset before this change. > > This reminds me, is there a way to delete a keep-state rule without > also deleting the dynamic rules it spawned? no, in the current implementation the dynamic rule references the parent to know what the action is. What you _can_ do is disable the set containing the parent rule. This will prevent the parent rule from matching (thus spawning new rules) but will still allow the dynamic rule to match and do the action specified. [if anyone feels like adding the above comment to the ipfw manpage, please do it] cheers luigi