From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 4 06:44:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D43A316A4D0 for ; Thu, 4 Dec 2003 06:44:41 -0800 (PST) Received: from smtp0.euronet.nl (smtp0.euronet.nl [194.134.35.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4837743FF3 for ; Thu, 4 Dec 2003 06:44:38 -0800 (PST) (envelope-from dodell@sitetronics.com) Received: from [192.168.1.42] (zp-c-13e65.mxs.adsl.euronet.nl [81.69.92.101]) by smtp0.euronet.nl (Postfix) with ESMTP id E952A24788; Thu, 4 Dec 2003 15:44:36 +0100 (MET) In-Reply-To: <200312041528.47226.zec@tel.fer.hr> References: <05CEBB5C-2664-11D8-AAE8-000A95E5E66E@sitetronics.com> <200312041528.47226.zec@tel.fer.hr> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <62090848-2668-11D8-AAE8-000A95E5E66E@sitetronics.com> Content-Transfer-Encoding: 7bit From: Devon H.O'Dell Date: Thu, 4 Dec 2003 15:44:37 +0100 To: Marko Zec X-Mailer: Apple Mail (2.606) cc: freebsd-hackers@freebsd.org Subject: Re: IPFW and the IP stack X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 14:44:41 -0000 Op 4-dec-03 om 15:28 heeft Marko Zec het volgende geschreven: > On Thursday 04 December 2003 15:13, Devon H.O'Dell wrote: >> I've been looking through the IP stack for shits and giggles and was >> wondering why a few things are the way they are with IPFW's >> implementation. >> >> I went back through the CVSWeb stuff to check out the changes and it >> appears that most of my questions are purely cosmetic issues; but I >> still don't understand them. >> >> Specifically, pretty much everything in the iphack: section relied on >> IPFW being defined in the kernel configuration. Several checks went >> away when COMPAT_IPFW was defaulted into the kernel, then several >> were removed to make a buildable kernel without having options >> IPFIREWALL defined in the kernel configuration. Throughout these >> changes, several variables related to IPFW were removed from #ifdef >> IPFIREWALL checks. At this point, most IPFW variables are initialized >> by default (including some stuff for natd) and every call to >> ip_input() does a check at if (fw_enable && IPFW_LOADED) (I believe >> this is true for ip_output() as well). Why are these variables and >> sections compiled in by default instead of left out if no firewall is >> existent in the kernel? > > Perhaps to allow for IPFW to be loaded as a module? > > Marko *slaps self* This is obviously the most logical explanation. There's a good bit of questioning for PFIL_HOOKS to be enabled in generic to allow ipf to be loaded as a module as well. If this is the case, we'll have two firewalls that have their hooks compiled in by default allowing for them both to be loaded as modules. (Is this still scheduled for 5.2?) But at this point, there's no way to allow one to turn the IPFW hooks *off*. Is there a reason for this? Would it be beneficial (or possible) to hook ipfw into pfil(9)? This way, we could allow the modules to be loaded by default for both and also allow for the total absence of both in the kernel. Sorry if I've missed discussions on this and am being redundant. --Devon