Date: Sat, 25 Mar 2000 22:19:05 -0500 From: Tom Legg <tjlegg@shore.net> To: freebsd-stable@freebsd.org Subject: Minor rc.network bug for 4.0 and ipfw Message-ID: <p04310101b5032cb2a0b9@[207.244.92.51]>
next in thread | raw e-mail | index | archive | help
I don't want to file a bug report for this until I can hear some discussion about the direction of ipfw. (is FreeBSD moving towards a system that prefers loading modules like ipfw for machines that might prefer denying all lkm?) The current situation creates a potential problem for 4.0 admins (at least I didn't notice it until I upgraded to the 4.0 kernel) 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 sysctl value to the "default". I would think a better approach would be to keep the kernel code with enable=0 and then let /etc/rc.network load the kernel modules if necessary and enable the firewall if firewall_enable="yes". -- ----- Tom Legg tjlegg@shore.net http://www.shore.net/~tjlegg/ 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?p04310101b5032cb2a0b9>