Re: -E flag in /etc/rc.d/ipfilter causes warnings
I believe it's harmless, and while not aesthetically pleasing, it's a necessary
work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so
it's necessary to use -E with the start command because there's no way to know
how/when/why/in-what-environment it's being called. If I'm wrong or you have a
better alternative to this please let me know.
Yes, you understood the manpage right and no, I don't think there's a
better way to detect that. This is something I've thought about and
couldn't come up with a better solution, either. But there's another
issue about /etc/rc.d/ipfilter that has a work-around: IPv6 support.
The current script just fires ipf and then ipf -6, whether you have
IPv6 support or not.
I don't know the purpose of this, since grepping /etc/rc* and
/etc/rc.d/* for it doesn't return anything, but there's this line in
/etc/defaults/rc.conf:
ipv6_enable=NO# Set to YES to set up for IPv6.
So, assuming there *is* a reason for that variable, I changed my
/etc/rc.d/ipfilter a bit so it respects that (although only in
ipfilter_start()):
case ${OSTYPE} in
FreeBSD)
${ipfilter_program:-/sbin/ipf} -Fa
if [ -r ${ipfilter_rules} ]; then
${ipfilter_program:-/sbin/ipf} \
-f ${ipfilter_rules} ${ipfilter_flags}
fi
case ${ipv6_enable} in
[Yy][Ee][Ss])
${ipfilter_program:-/sbin/ipf} -6 -Fa
if [ -r ${ipv6_ipfilter_rules} ]; then
${ipfilter_program:-/sbin/ipf} -6 \
-f ${ipv6_ipfilter_rules} ${ipfilter_flags}
fi
;;
esac
;;
Should that be the default, or am I missing anything here?
Fred
--
They're only trying to make me LOOK paranoid!
pgp0.pgp
Description: PGP signature
Re: -E flag in /etc/rc.d/ipfilter causes warnings
On 16 Jun 2003 21:35:44 -0400 Mike Bohan [EMAIL PROTECTED] wrote: Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). hmm... I thought it was the other way around (it's not effective when loaded as a module), but I may have misunderstood the man page. This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! I believe it's harmless, and while not aesthetically pleasing, it's a necessary work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so it's necessary to use -E with the start command because there's no way to know how/when/why/in-what-environment it's being called. If I'm wrong or you have a better alternative to this please let me know. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -E flag in /etc/rc.d/ipfilter causes warnings
That's actually how I interpreted the man page too (the way you did), but rc.conf says the inverse, and my testing corresponds to this as well... ipfilter_flags= # should be *empty* when ipf is _not_ a module # (i.e. compiled into the kernel) to # avoid a warning about already initialized I agree there's no easy solution with the rc.d start/stop functionality. I'll let the list know if I come up with an alternate method. -- Mike Bohan [EMAIL PROTECTED] On Mon, 2003-06-16 at 22:39, Mike Makonnen wrote: On 16 Jun 2003 21:35:44 -0400 Mike Bohan [EMAIL PROTECTED] wrote: Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). hmm... I thought it was the other way around (it's not effective when loaded as a module), but I may have misunderstood the man page. This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! I believe it's harmless, and while not aesthetically pleasing, it's a necessary work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so it's necessary to use -E with the start command because there's no way to know how/when/why/in-what-environment it's being called. If I'm wrong or you have a better alternative to this please let me know. Cheers. signature.asc Description: This is a digitally signed message part
