Subject: Re: HEADS UP: IPFilter upgraded to 3.4.29
To: David Laight <firstname.lastname@example.org>
From: Andrew Brown <email@example.com>
Date: 09/19/2002 12:06:05
>> There was a time (a very long time ago) when upgrading the kernel would
>> have broken existing setups if the default would have been "block all".
>> IIRC ipf itself changed the default.
>Doesn't that tend to happen now, every time ipf gets updated.
only if you upgrade your kernel and not the corresponding userland
tools. that's trivial to do; i do it all the time, and mostly
>Or has someone managed to get the code to use ioctl requests
>and versioning so that the new utils can load an old kernel?
>(and coding for binary compatibility so that a new kernel
>can be loaded with the old rules by the old utils.)
there's a bit more to it than that, i think, but i haven't looked
recently enough for the memory of it to be fresh enough in my head.
>> Think of sites without any ipf rules (ipf is in GENERIC).
>I was thinking that ipf could load a 'pass all' ruleset from
>the rc script 'as shipped'. But once configured that would
>no longer happen.
it also prevents some remote diagnostics from working. something like
ping can tell you that the machine got as far as setting up the
network, but if ipf defaults to dropping all packets, you can't even
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."