and network stack, several locks acquired in the path of each packet,
and i have an ability to test this in the lab.
So, i prepared the patch, that removes IPFIREWALL_FORWARD option from
the kernel and makes this functionality always build-in, but it is
turned off by default and can be enabled via
an ability to test this in the lab.
So, i prepared the patch, that removes IPFIREWALL_FORWARD option from
the kernel and makes this functionality always build-in, but it is
turned off by default and can be enabled via the sysctl(8) variable
net.pfil.forward=1.
http://people.freebsd.org/~ae
and network stack, several locks acquired in the path of each packet,
and i have an ability to test this in the lab.
So, i prepared the patch, that removes IPFIREWALL_FORWARD option from
the kernel and makes this functionality always build-in, but it is
turned off by default and can be enabled via
acquired in the path of each packet,
and i have an ability to test this in the lab.
So, i prepared the patch, that removes IPFIREWALL_FORWARD option from
the kernel and makes this functionality always build-in, but it is
turned off by default and can be enabled via the sysctl(8) variable
On 19.10.2012 16:02, Andre Oppermann wrote:
http://people.freebsd.org/~ae/pfil_forward.diff
Also we have done some tests with the ixia traffic generator connected
via 10G network adapter. Tests have show that there is no visible
difference, and there is no visible performance degradation.
and network stack, several locks acquired in the path of each packet,
and i have an ability to test this in the lab.
So, i prepared the patch, that removes IPFIREWALL_FORWARD option from
the kernel and makes this functionality always build-in, but it is
turned off by default and can be enabled
On 19.10.2012 18:05, Andre Oppermann wrote:
On 19.10.2012 14:18, Andrey V. Elsukov wrote:
On 19.10.2012 16:02, Andre Oppermann wrote:
http://people.freebsd.org/~ae/pfil_forward.diff
Also we have done some tests with the ixia traffic generator connected
via 10G network adapter. Tests have show
Hi Andre Oppermann!
On Fri, 19 Oct 2012 16:05:42 +0200; Andre Oppermann wrote about 'Re: [RFC]
Enabling IPFIREWALL_FORWARD in run-time':
On 19.10.2012 14:18, Andrey V. Elsukov wrote:
On 19.10.2012 16:02, Andre Oppermann wrote:
http://people.freebsd.org/~ae/pfil_forward.diff
Also we have
On Mon, 27 Sep 2010, c0re wrote:
Is there any possibility to see IPFIREWALL_FORWARD option for ipfw.ko
in GENERIC?
Were there any patches about that?
I like freebsd-update, but lacking IPFIREWALL_FORWARD in GENERIC stops
me from using freebsd-update.
In a nutshell, no. This thread
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
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
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
' 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
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'
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
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 -
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
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
18 matches
Mail list logo
