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
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
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
>Andrey V. Elsukov wrote:
>This introduces quite a bit of extra code into the path of IP packets.
Yes, it will add a few extra checks like a "if (pfil_forward_enabled) {...}"
>Some people are very sensitive about anything that slows down that path.
I can introduce a new kernel option - NO_PFIL_F
Andrey V. Elsukov wrote:
Hi, All!
I want get the IPFIREWALL_FORWARD feature without a kernel rebuild.
And use forwarding with the ipfw kld. It's possible to have this
functional in the base system? If yes, then which is preferred way:
sysctl or kld?
This introduces quite a bit of
Hi, All!
I want get the IPFIREWALL_FORWARD feature without a kernel rebuild.
And use forwarding with the ipfw kld. It's possible to have this
functional in the base system? If yes, then which is preferred way:
sysctl or kld?
--
WBR, Andrey V. El
Hello everybody,
A kernel panic has been observed in both branches under the following
conditions:
o ipfw is configured with a "fwd" rule for outgoing packets that will
match some RIP datagrams
o GateD is started with RIP enabled and consequently sends a broadcast
UDP datagram that matches th
Here is a fixed version of this patch. last one used an unitialised
variable.
Note: the whole ipfw/fwd scheme is non re-entrant. to fix it and some
other parts
of the code will require that we gain teh capability of associating
extra state with a packet.. e.g. "this packet has been diverted"
or
ethfw should be implemented as a negraph module...
(all teh hooks are already there)
On Fri, 16 Nov 2001, Mikel King wrote:
> Chrisy Luke wrote:
>
> > Mikel King wrote (on Nov 16):
> > > Just curious, but what's a doddle?
> >
> > It's like a doodle, but with less o's and more d's. :)
> >
> > I
A "doddle" is "a task so easy that you could do it in your sleep"
(BTW the patch has a small bug.. but the fix is trivial.)
On Fri, 16 Nov 2001, Mikel King wrote:
> Just curious, but what's a doddle?
>
> Cheers,
> mikel
>
> Julian Elischer wrote:
>
> > On Thu, 15 Nov 2001, Chrisy Luke wrot
Chrisy Luke wrote:
> Mikel King wrote (on Nov 16):
> > Just curious, but what's a doddle?
>
> It's like a doodle, but with less o's and more d's. :)
>
> It essentially means "this is easy to do".
>
> Chris.
> --
> == [EMAIL PROTECTED]T: +44 845 333 0122
> == Gl
Mikel King wrote (on Nov 16):
> Just curious, but what's a doddle?
It's like a doodle, but with less o's and more d's. :)
It essentially means "this is easy to do".
Chris.
--
== [EMAIL PROTECTED]T: +44 845 333 0122
== Global IP Network Engineering, Easynet G
Just curious, but what's a doddle?
Cheers,
mikel
Julian Elischer wrote:
> On Thu, 15 Nov 2001, Chrisy Luke wrote:
> > > > only packets already leaving the system can be hijacked and forwarded
> > > > to a 2nd machine. Incoming packets can only be forwarded to local
> > > > addresses/port combin
On Thu, 15 Nov 2001, Chrisy Luke wrote:
> > > only packets already leaving the system can be hijacked and forwarded
> > > to a 2nd machine. Incoming packets can only be forwarded to local
> > > addresses/port combinations.
>
> My fault. I was being lazy when I wrote it. :)
Ah it WAS you I comm
Excuse me feollowing up to myself, but...
Chrisy Luke wrote (on Nov 15):
> It looks good. The ipfw syntax doesn't quite make sense to me.
> Also, are you requiring that they all be on the same ipfw rule number?
Ignore this. Just occured to me you're sharing load based on a netmask.
A small stat
Julian Elischer wrote (on Nov 15):
> Oops forgot the patch.. here it is...
I almost replied to the first - too quick off the mark!
> Julian Elischer wrote:
> > Ipfw 'fwd' at present has teh following restriction:
> >
> > only packets already leaving the system can be hijacked and forwarded
>
Oops forgot the patch.. here it is...
Julian Elischer wrote:
>
> The following patch is expected to
> allow the forwarding of INCOMING packets to an arbitrary next hop
> controlled by the ipfw fwd command..
>
> Ipfw 'fwd' at present has teh following restriction:
>
> only packets already le
The following patch is expected to
allow the forwarding of INCOMING packets to an arbitrary next hop
controlled by the ipfw fwd command..
Ipfw 'fwd' at present has teh following restriction:
only packets already leaving the system can be hijacked and forwarded
to a 2nd machine. Incoming packet
29 matches
Mail list logo
