Al Boldi wrote:
[EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
Sure, the idea was to mark the filter table obsolete as to make people
start using the mangle table to do their filtering for new setups. The
filter table would then still be available for
Al Boldi wrote:
[EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
Sure, the idea was to mark the filter table obsolete as to make people
start using the mangle table to do their filtering for new setups. The
filter table would then still be available for
On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said:
> > Well, for example to stop any transient packets being forwarded. You could
> > probably hack around this using mark's, but you can't stop the implied
> > route lookup, unless you stop it in prerouting.
>
> Basically, you have one big
[EMAIL PROTECTED] wrote:
> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> > Sure, the idea was to mark the filter table obsolete as to make people
> > start using the mangle table to do their filtering for new setups. The
> > filter table would then still be available for legacy/special
On Oct 20 2007 00:47, [EMAIL PROTECTED] wrote:
>> Sure, the idea was to mark the filter table obsolete as to make people start
>> using the mangle table to do their filtering for new setups. The filter
>> table would then still be available for legacy/special setups. But this
>> would only
On Oct 20 2007 00:47, [EMAIL PROTECTED] wrote:
Sure, the idea was to mark the filter table obsolete as to make people start
using the mangle table to do their filtering for new setups. The filter
table would then still be available for legacy/special setups. But this
would only be
[EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
Sure, the idea was to mark the filter table obsolete as to make people
start using the mangle table to do their filtering for new setups. The
filter table would then still be available for legacy/special setups.
On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said:
Well, for example to stop any transient packets being forwarded. You could
probably hack around this using mark's, but you can't stop the implied
route lookup, unless you stop it in prerouting.
Basically, you have one big unintended
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> Sure, the idea was to mark the filter table obsolete as to make people start
> using the mangle table to do their filtering for new setups. The filter
> table would then still be available for legacy/special setups. But this
> would only
Bill Davidsen wrote:
> Bill Davidsen wrote:
> If not, then shouldn't the filter table be obsoleted to avoid
> confusion?
> >>>
> >>> That would probably confuse people. Just don't use it if you don't
> >>> need to.
> >
> > That is a most practical suggestion.
> >
> >> The problem is that
Bill Davidsen wrote:
Bill Davidsen wrote:
If not, then shouldn't the filter table be obsoleted to avoid
confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
Sure, the idea was to mark the filter table obsolete as to make people start
using the mangle table to do their filtering for new setups. The filter
table would then still be available for legacy/special setups. But this
would only be
Hey all
I'm using netperf to perform TCP throughput tests via the localhost
interface. This is being done on a SMP machine. I'm forcing the
netperf server and client to run on the same core. However, for any
packet sizes below 523 the throughput is much lower compared to the
throughput when the
Hey all
I'm using netperf to perform TCP throughput tests via the localhost
interface. This is being done on a SMP machine. I'm forcing the
netperf server and client to run on the same core. However, for any
packet sizes below 523 the throughput is much lower compared to the
throughput when the
Bill Davidsen wrote:
If not, then shouldn't the filter table be obsoleted to avoid
confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with the filter table,
when in fact
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than
Bill Davidsen wrote:
If not, then shouldn't the filter table be obsoleted to avoid
confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with the filter table,
when in fact
Al Boldi wrote:
Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and "built-in"
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be
Patrick McHardy wrote:
> Al Boldi wrote:
> > But can you see how forcing people into splitting
> > their rules across tables adds complexity. And without ipt_REJECT
> > patch, they can't even use REJECT in prerouting, which forces them to do
> > some strange hacks.
> >
> > IMHO, we should make
Patrick McHardy wrote:
> Jan Engelhardt wrote:
> > On Oct 12 2007 16:30, Al Boldi wrote:
> With the existence of the mangle table, how useful is the filter
> table?
> >>>
> >>>A similar discussion was back in March 2007.
> >>>http://marc.info/?l=netfilter-devel=117394977210823=2
>
Jan Engelhardt wrote:
> On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>>The netlink based iptables successor I'm currently working on allows to
>>dynamically create tables with user-specified priorities and "built-in"
>>chains. The only built-in tables will be those that need extra
>>processing
On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>The netlink based iptables successor I'm currently working on allows to
>dynamically create tables with user-specified priorities and "built-in"
>chains. The only built-in tables will be those that need extra
>processing (mangle/nat). So it should
Jan Engelhardt wrote:
> On Oct 12 2007 16:30, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
>>>
>>>A similar discussion was back in March 2007.
>>>http://marc.info/?l=netfilter-devel=117394977210823=2
On Oct 12 2007 16:30, Al Boldi wrote:
>Jan Engelhardt wrote:
>> On Oct 12 2007 00:31, Al Boldi wrote:
>> >With the existence of the mangle table, how useful is the filter table?
>>
>> A similar discussion was back in March 2007.
>> http://marc.info/?l=netfilter-devel=117394977210823=2
>>
Jan Engelhardt wrote:
> On Oct 12 2007 00:31, Al Boldi wrote:
> >With the existence of the mangle table, how useful is the filter table?
>
> A similar discussion was back in March 2007.
> http://marc.info/?l=netfilter-devel=117394977210823=2
> http://marc.info/?l=netfilter-devel=117400063907706=2
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>Al Boldi wrote:
>>
>>>Well, for example to stop any transient packets being forwarded. You
>>>could probably hack around this using mark's, but you can't stop the
>>>implied route lookup, unless you stop it in prerouting.
>>
>>This also works fine in
Patrick McHardy wrote:
> Al Boldi wrote:
> >>>The problem is that people think they are safe with the filter table,
> >>>when in fact they need the prerouting chain to seal things. Right now
> >>>this is only possible in the mangle table.
> >>
> >>Why do they need PREROUTING?
> >
> > Well, for
On Oct 12 2007 00:31, Al Boldi wrote:
>
>With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-devel=117394977210823=2
http://marc.info/?l=netfilter-devel=117400063907706=2
in the end, my proposal was
Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things. Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
>
>
> Well, for example to stop any transient packets
Patrick McHardy wrote:
> Al Boldi wrote:
> > Patrick McHardy wrote:
> >>Please send mails discussing netfilter to netfilter-devel.
> >
> > Ok. I just found out this changed to vger. But
> > [EMAIL PROTECTED] is bouncing me.
>
> Seems to work, I got your mail on netfilter-devel.
Looks like it
On Oct 12 2007 16:30, Al Boldi wrote:
Jan Engelhardt wrote:
On Oct 12 2007 00:31, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
Jan Engelhardt wrote:
On Oct 12 2007 00:31, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter-develm=117400063907706w=2
On Oct 12 2007 00:31, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter-develm=117400063907706w=2
in the end, my proposal was
Al Boldi wrote:
Patrick McHardy wrote:
Al Boldi wrote:
Well, for example to stop any transient packets being forwarded. You
could probably hack around this using mark's, but you can't stop the
implied route lookup, unless you stop it in prerouting.
This also works fine in FORWARD with a
On Oct 12 2007 15:48, Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be
Jan Engelhardt wrote:
On Oct 12 2007 15:48, Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing
Patrick McHardy wrote:
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Seems to work, I got your mail on netfilter-devel.
Looks like it works sometimes.
Al Boldi wrote:
The problem is that people think they are safe with the filter table,
when in fact they need the prerouting chain to seal things. Right now
this is only possible in the mangle table.
Why do they need PREROUTING?
Well, for example to stop any transient packets being
Jan Engelhardt wrote:
On Oct 12 2007 16:30, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter-develm=117400063907706w=2
in
Patrick McHardy wrote:
Al Boldi wrote:
The problem is that people think they are safe with the filter table,
when in fact they need the prerouting chain to seal things. Right now
this is only possible in the mangle table.
Why do they need PREROUTING?
Well, for example to stop any
Patrick McHardy wrote:
Jan Engelhardt wrote:
On Oct 12 2007 16:30, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter
table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
Patrick McHardy wrote:
Al Boldi wrote:
But can you see how forcing people into splitting
their rules across tables adds complexity. And without ipt_REJECT
patch, they can't even use REJECT in prerouting, which forces them to do
some strange hacks.
IMHO, we should make things as
Al Boldi wrote:
Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be
Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
> Al Boldi wrote:
> > With the existence of the mangle table, how useful is the filter table?
> >
> > Other than requiring the
Please send mails discussing netfilter to netfilter-devel.
Al Boldi wrote:
> With the existence of the mangle table, how useful is the filter table?
>
> Other than requiring the REJECT target to be ported to the mangle table, is
> the filter table faster than the mangle table?
There are some
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
If not, then shouldn't the filter table be obsoleted to avoid confusion?
Thanks!
--
Al
-
To
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
If not, then shouldn't the filter table be obsoleted to avoid confusion?
Thanks!
--
Al
-
To
Please send mails discussing netfilter to netfilter-devel.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
There are some minor
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT
50 matches
Mail list logo
