From owner-cvs-all@FreeBSD.ORG Tue Jul 20 01:09:05 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id BC88D16A4CF; Tue, 20 Jul 2004 01:09:05 +0000 (GMT) Date: Tue, 20 Jul 2004 01:09:05 +0000 From: Darren Reed To: Max Laier Message-ID: <20040720010905.GB63588@hub.freebsd.org> References: <200407170240.i6H2eEHO021683@repoman.freebsd.org> <200407170538.14572.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407170538.14572.max@love2party.net> User-Agent: Mutt/1.4.1i cc: Juli Mallett cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw2.c src/sys/sys mbuf.h 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: Tue, 20 Jul 2004 01:09:06 -0000 On Sat, Jul 17, 2004 at 05:38:07AM +0200, Max Laier wrote: > On Saturday 17 July 2004 04:40, Juli Mallett wrote: > > Log: > > Make M_SKIP_FIREWALL a global (and semantic) flag, preventing anything > > from using M_PROTO6 and possibly shooting someone's foot, as well as > > allowing the firewall to be used in multiple passes, or with a packet > > classifier frontend, that may need to explicitly allow a certain packet. > > Presently this is handled in the ipfw_chk code as before, though I have run > > with it moved to upper layers, and possibly it should apply to ipfilter and > > pf as well, though this has not been investigated. > > pf does something to the same effect by prepending a mbuf with the > "PACKET_TAG_PF_GENERATED" mbuf_tag to skip processing for its own packets. If > we can agree that the presence of M_SKIP_FIREWALL is copied to icmp error > messages I will happily replace the mbuf tag with the more general flag > (which will perform significantly better, I believe). Please tell me what you > think of this. Hmmm...personally, I think it is better if firewall packages only ignore what they've generated themselves. If you're using multiple ones together, you may wish to use one as a gap filler that is able to manage the "output" of another. Darren