From owner-freebsd-ipfw@FreeBSD.ORG Sun May 9 01:17:00 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 4A45416A4CE for ; Sun, 9 May 2004 01:17:00 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2960B43D2D for ; Sun, 9 May 2004 01:17:00 -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 i498Gxgd053698; Sun, 9 May 2004 01:16:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i498Gx0i053697; Sun, 9 May 2004 01:16:59 -0700 (PDT) (envelope-from rizzo) Date: Sun, 9 May 2004 01:16:59 -0700 From: Luigi Rizzo To: "Louis A. Mamakos" Message-ID: <20040509011659.A52837@xorpc.icir.org> 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> <20040509020814.61BB120F78@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040509020814.61BB120F78@whizzo.transsys.com>; from louie@transsys.com on Sat, May 08, 2004 at 10:08:14PM -0400 cc: freebsd-ipfw@freebsd.org cc: Oleg Bulyzhin 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 08:17:00 -0000 On Sat, May 08, 2004 at 10:08:14PM -0400, Louis A. Mamakos wrote: > > 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.) actually i don't think the 'divert' behaviour was intentional, but just a side effect of the fact that the only visible rule identifier in userland is the rule number, and so you couldn't do otherwise. For dummynet pipes the situation is different as you remain in the kernel as packets remain in the kernel so you can keep track correctly of the matching rule and locate the next one. I understand that what you propose can be used to implement a 'switch' block, but i wonder if changing the behaviour now wouldn't break POLA... cheers luigi > 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