Re: [patch] move ipfw logging to after syslogd

From: Ian FREISLICH <ianf_at_clue.co.za>
Date: Thu, 12 Apr 2007 07:18:02 +0200
Gavin Atkinson wrote:
> On Wed, 2007-04-11 at 15:49 +0200, Ian FREISLICH wrote:
> > Hi
> > 
> > We have a problem that on our busy firewalls, a boot and shutdown
> > can be delayed by up to 20 minutes by the kernel printing log
> > messages for denied packets to the console.  The problem is that
> > most kernel activity appears to be suspended by outputting ipfw
> > logged messages via the serial console (but not even the video
> > console keeps up).  The kernel doesn't even respond to a serial
> > break.
> 
> I wonder if a better fix is to ensure syslogd is started before bringing
> up the network?  That way, you won't need this, as before IP addresses
> are configured, you shouldn't get hit by anything.  Of course, this
> would be an issue for when syslog is set to log remotely, unless that
> laready has some "caching" mechanism to prevent messages being thrown
> away.

I'd be happy with that so long as the firewall script is included
in the shutdown process and it sets net.inet.ip.fw.verbose=0 before
syslogd is killed.

> 
> >  	if [ -r "${firewall_script}" ]; then
> >  		if [ -f /etc/rc.d/natd ] ; then
> >  			/etc/rc.d/natd start
> >  		fi
> > -		/bin/sh "${firewall_script}"
> > +		. "${firewall_script}"
> >  		echo 'Firewall rules loaded.'
> >  	elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then
> >  		echo 'Warning: kernel has firewall functionality, but' \
> > _at__at_ -34,13 +40,6 _at__at_
> >  		echo '           All ip services are disabled.'
> >  	fi
> >  
> 
> Be careful, it looks like this unintentionally backs out the 1.15
> change.

Ooops.  I did notice that and I thought I fixed it.

On a side note, a colleague of mine noted that a side-effect of
this change is that the kernel option IPFIREWALL_VERBOSE is rendered
pretty much useless.  It's pretty much useless anyway because it's
a knob in rc.conf.

Ian

--
Ian Freislich
Received on Thu Apr 12 2007 - 03:19:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:08 UTC