IPFIREWALL_FORWARD

[Julian Elischer]

Chris St Denis wrote:
> Julian Elischer wrote:
>> n j wrote:
>>> Hello,
>>>
>>> although this has probably been asked before, could anyone point me to
>>> some relevant information about why fwd/forward requires kernel
>>> recompile, i.e. it's not been made a kernel module? This prevents me
>>> from using freebsd-update and forces me to upgrade from source which -
>>> even though we all like and love building from source, ofcourse :) -
>>> is quite more complicated than the binary upgrade.
>>>
>>> Thanks,
>>
>> because when I first committed it I knew that as it broke some
>> expected behaviour and added some instructions to the path for
>> all incoming  and outgoing packets, that if I didn't make it
>> an option,  I would never be allowed to commit it..
>>
>> since then the same reasons have continued..
>> it adds several tests, not all of which are cheap,
>> to the packet path.
>>
>> We could make is dependent on some sysctl
>> or something to take out the most expensive tests..
>> but we really need to look at the overall picture of 'extensions'
>> and whether there is a general way to handle them.
> Is there some reason why it can't just be made a loadable module?
> 


A loadable module requires a coherent piece of code to implement the
functionality, that can be put into the module. This option
scatters tiny snippets of code throughout the exisitng
TCP/UDP/IP/ipfw code.