Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Mar 2000 16:18:12 +0200 (CEST)
From:      Luigi Rizzo <luigi@info.iet.unipi.it>
To:        Tom Legg <tjlegg@shore.net>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Minor rc.network bug for 4.0 and ipfw
Message-ID:  <200003261418.QAA19680@info.iet.unipi.it>
In-Reply-To: <p04310101b5032cb2a0b9@[207.244.92.51]> from Tom Legg at "Mar 25, 2000 10:19:05 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003261418.QAA19680>