From owner-freebsd-stable Sun Mar 26 6:17:31 2000 Delivered-To: freebsd-stable@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 2C03437B9DE for ; Sun, 26 Mar 2000 06:17:25 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id QAA19680; Sun, 26 Mar 2000 16:18:12 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200003261418.QAA19680@info.iet.unipi.it> Subject: Re: Minor rc.network bug for 4.0 and ipfw In-Reply-To: from Tom Legg at "Mar 25, 2000 10:19:05 pm" To: Tom Legg Date: Sun, 26 Mar 2000 16:18:12 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since I was the one who introduced net.inet.ip.fw.enable ... The variable was inserted so that one could independently choose to use the firewall at the IP level, or at the bridging level, or at both places. Soon after that i introduced the 'bridged' specifier in ipfw rules which rendered the variable partly superflous for the above purpose, except that it helps in some cases when one wants to debug a ruleset and temporarily bring the machine online whitout deleting the entire ruleset (e.g. think of remote management: you build a script that introduces the new ruleset, sets net.inet.ip.fw.enable=1, and if no confirmation arrives within the next 15 seconds brings the variable back to 0 so a remote admin can try sort things out). So i dont think rc.network should touch the sysctl variable depending on the shell variable firewall_enable. cheers luigi > If you compile a kernel with ipfw in the kernel but do nothing to > modify /etc/defaults/rc.conf and boot, net.inet.ip.fw.enable is set > to 1 and since the defaults for enable is NO, no further action is > done upon the firewall scripts. > > Since the current /etc/rc.network only seems to check for > firewall_enable="yes", it doesn't seem to reverse the default (which > is enable=1) and at the same time doesn't read any of the options > about what type of firewall the user would like. I've written a test > patch for /etc/rc.network that checks for the case > firewall_enable="no" and set net.inet.ip.fw.enable to 0. (note: this > has to go at least before the dhcp client invocation *grin*) But > something seems wrong about doing a check during a boot to reset the To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message