IPFW and the IP stack

[Devon H.O'Dell]

Op 4-dec-03 om 15:28 heeft Marko Zec het volgende geschreven:

> On Thursday 04 December 2003 15:13, Devon H.O'Dell wrote:
>> I've been looking through the IP stack for shits and giggles and was
>> wondering why a few things are the way they are with IPFW's
>> implementation.
>>
>> I went back through the CVSWeb stuff to check out the changes and it
>> appears that most of my questions are purely cosmetic issues; but I
>> still don't understand them.
>>
>> Specifically, pretty much everything in the iphack: section relied on
>> IPFW being defined in the kernel configuration. Several checks went
>> away when COMPAT_IPFW was defaulted into the kernel, then several
>> were removed to make a buildable kernel without having options
>> IPFIREWALL defined in the kernel configuration. Throughout these
>> changes, several variables related to IPFW were removed from #ifdef
>> IPFIREWALL checks. At this point, most IPFW variables are initialized
>> by default (including some stuff for natd) and every call to
>> ip_input() does a check at if (fw_enable && IPFW_LOADED) (I believe
>> this is true for ip_output() as well). Why are these variables and
>> sections compiled in by default instead of left out if no firewall is
>> existent in the kernel?
>
> Perhaps to allow for IPFW to be loaded as a module?
>
> Marko

*slaps self*

This is obviously the most logical explanation. There's a good bit of 
questioning for PFIL_HOOKS to be enabled in generic to allow ipf to be 
loaded as a module as well. If this is the case, we'll have two 
firewalls that have their hooks compiled in by default allowing for 
them both to be loaded as modules. (Is this still scheduled for 5.2?)

But at this point, there's no way to allow one to turn the IPFW hooks 
*off*. Is there a reason for this?

Would it be beneficial (or possible) to hook ipfw into pfil(9)? This 
way, we could allow the modules to be loaded by default for both and 
also allow for the total absence of both in the kernel. Sorry if I've 
missed discussions on this and am being redundant.

--Devon