Date: Thu, 15 Aug 2002 11:38:25 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Julian Elischer <julian@elischer.org> Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815113824.B30190@iguana.icir.org> In-Reply-To: <Pine.BSF.4.21.0208151042200.27476-100000@InterJet.elischer.org>; from julian@elischer.org on Thu, Aug 15, 2002 at 10:49:22AM -0700 References: <20020815000720.B24495@iguana.icir.org> <Pine.BSF.4.21.0208151042200.27476-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 15, 2002 at 10:49:22AM -0700, Julian Elischer wrote: ... > A bit to force non testing in a firewall might be useful in other places.. > I'd however like to float an idea that maybe there should be more > specific bits for input and output processing. unfortunately bits are a scarce resource in struct m_hdr which we do not want to change in RELENG_4. Plus, many of the cases you are mentioning are already taken care of with m_tag/annotations because you need additional information: e.g. in the "fwd" you need the fwd address anyways, same for divert (you need the 'next rule'), and dummynet when you want multiple passes. The problem with protocol-specific bits is that you'll end up overloading them, and once you pass the packets to a multi-protocol module (such as netgraph, or ipfw2) you are in trouble. E.g. M_PROTO1 has been overloaded by device drivers to report some vlan-related info. The other M_PROTO* are all taken by the KAME code. cheers luigi > > > for example a 'fwd' packet that has been forwarded out from thi input > filter needs to bypass the output filter.. your bit could be used for > that. I am just wondering if a separate > 'input' and 'output' filtering bit may be a worthwhile aim.. > anyhow these are IP specific items so what I suggest is instead, that we > define 4 or so "protocol family specific" bits > that are reserved for protocol use. and allow each protocol family to > define their own use for them. > > you could then define bits for > input-filter bypass, > output filter bypass, > input-from-divert > > > etc. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815113824.B30190>