ork adapters, SMP kernel
>> 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 alway
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
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 d
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
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.fr
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 sho
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 that there is no visible
difference, and th
ers, SMP kernel
> 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
>
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 degradat
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
rs, SMP kernel
> 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
> tu
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
Thanks Ian.
Looks like switching to pf is the only option now.
2010/9/27 Ian Smith :
> 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 li
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 nuts
Hello freebsd-ipfw!
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.
___
freebsd
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 t
> 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 repli
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
on 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
> 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 f
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 a
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
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 -
eve
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 a
24 matches
Mail list logo
