Re: IPFIREWALL_FORWARD
it's needed for the functionality. you need to slightly change the behaviour or the existing stack in quite a number of places to handle a forwarded packet. Sorry for catching up with the thread so late, I was without Internet connection for the last couple of days. Thanks for all the replies so far, I've got just one more question: is it correct that pf (as loadable module) has this forward (aka route-to) functionality without needing the kernel recompile? If so, it might be that final push for me to switch from ipfw to pf. Regards, -- Nino ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
n j wrote: it's needed for the functionality. you need to slightly change the behaviour or the existing stack in quite a number of places to handle a forwarded packet. Sorry for catching up with the thread so late, I was without Internet connection for the last couple of days. Thanks for all the replies so far, I've got just one more question: is it correct that pf (as loadable module) has this forward (aka route-to) functionality without needing the kernel recompile? If so, it might be that final push for me to switch from ipfw to pf. Regards, I can't answer for pf.. this is the ipfw mailing list. :-) If they do have the same functionality then they will need the same changes. If they do something different (e.g. changing the packet) then they may be able to do a subset of the same thing. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
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. Is that just a matter of current implementation or is that 'scatter' necessary for forward functionality? -- Nino ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
On Thu, 11 Mar 2010, n j wrote: 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. Is that just a matter of current implementation or is that 'scatter' necessary for forward functionality? I think what Julian's saying is that adding (ipfw-specific) forwarding code to that many code paths in the stack has been deemed too expensive to have it be costing execution time when it's not being used. If 'the stack' was a monolithic thing that could be loaded as a module, then loading different builds of it may be feasible .. but it isn't :) % grep -RHi IPFIREWALL_FORWARD /sys/ to scope the job of including it. I've no idea how costly wrapping that code with sysctl tests rather than ifdefs might be - maybe worth a test? - but there's always going to be pressure to maximise packet flows .. my 2 bob, Ian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
n j wrote: 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. Is that just a matter of current implementation or is that 'scatter' necessary for forward functionality? it's needed for the functionality. you need to slightly change the behaviour or the existing stack in quite a number of places to handle a forwarded packet. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
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. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
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? -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 --- Smart Internet Solutions For Businesses ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: IPFIREWALL_FORWARD
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. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
