LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFD] iptables:  mangle table obsoletes filter table
@ 2007-10-11 21:31 Al Boldi
  2007-10-12  4:35 ` Patrick McHardy
  2007-10-12 13:01 ` Jan Engelhardt
  0 siblings, 2 replies; 25+ messages in thread
From: Al Boldi @ 2007-10-11 21:31 UTC (permalink / raw)
  To: netfilter-devel, netdev; +Cc: linux-net, linux-kernel

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-11 21:31 [RFD] iptables: mangle table obsoletes filter table Al Boldi
@ 2007-10-12  4:35 ` Patrick McHardy
  2007-10-12  5:37   ` Al Boldi
  2007-10-12 13:01 ` Jan Engelhardt
  1 sibling, 1 reply; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12  4:35 UTC (permalink / raw)
  To: Al Boldi
  Cc: netfilter-devel, netdev, linux-net, linux-kernel,
	Netfilter Development Mailinglist

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 differences in ordering (mangle comes before
DNAT, filter afterwards), but for most rulesets thats completely
irrelevant. The only difference that really matters is that mangle
performs rerouting in LOCAL_OUT for packets that had their routing
key changed, so its really a superset of the filter table. If you
want to use REJECT in the mangle table, you just need to remove the
restriction to filter, it works fine. I would prefer to also remove
the restriction of MARK, CONNMARK etc. to mangle, they're used for
more than just routing today so that restriction also doesn't make
much sense. Patches for this are welcome.

> 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.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12  4:35 ` Patrick McHardy
@ 2007-10-12  5:37   ` Al Boldi
       [not found]     ` <470F5F19.70606@trash.net>
  2007-10-17 22:37     ` Bill Davidsen
  0 siblings, 2 replies; 25+ messages in thread
From: Al Boldi @ 2007-10-12  5:37 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, netdev, linux-net, linux-kernel

Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.

Ok.  I just found out this changed to vger.  But 
netfilter-devel@vger.kernel.org is bouncing me.

> 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 differences in ordering (mangle comes before
> DNAT, filter afterwards), but for most rulesets thats completely
> irrelevant. The only difference that really matters is that mangle
> performs rerouting in LOCAL_OUT for packets that had their routing
> key changed, so its really a superset of the filter table. If you
> want to use REJECT in the mangle table, you just need to remove the
> restriction to filter, it works fine. I would prefer to also remove
> the restriction of MARK, CONNMARK etc. to mangle, they're used for
> more than just routing today so that restriction also doesn't make
> much sense. Patches for this are welcome.

Something like this (untested):

--- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
+++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
 
 static inline void send_unreach(struct sk_buff *skb_in, int code)
 {
+       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
        icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
 }
 
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
        .family         = AF_INET,
        .target         = reject,
        .targetsize     = sizeof(struct ipt_reject_info),
-       .table          = "filter",
-       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
-                         (1 << NF_IP_LOCAL_OUT),
        .checkentry     = check,
        .me             = THIS_MODULE,
 };

> > 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.

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.



Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
       [not found]     ` <470F5F19.70606@trash.net>
@ 2007-10-12 12:25       ` Al Boldi
  2007-10-12 12:31         ` Patrick McHardy
  0 siblings, 1 reply; 25+ messages in thread
From: Al Boldi @ 2007-10-12 12:25 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, netdev, linux-kernel

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
> > netfilter-devel@vger.kernel.org is bouncing me.
>
> Seems to work, I got your mail on netfilter-devel.

Looks like it works sometimes.  Added lkml as a backup...

> >>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 differences in ordering (mangle comes before
> >>DNAT, filter afterwards), but for most rulesets thats completely
> >>irrelevant. The only difference that really matters is that mangle
> >>performs rerouting in LOCAL_OUT for packets that had their routing
> >>key changed, so its really a superset of the filter table. If you
> >>want to use REJECT in the mangle table, you just need to remove the
> >>restriction to filter, it works fine. I would prefer to also remove
> >>the restriction of MARK, CONNMARK etc. to mangle, they're used for
> >>more than just routing today so that restriction also doesn't make
> >>much sense. Patches for this are welcome.
> >
> > Something like this (untested):
> >
> > --- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
> > +++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
> > @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
> >
> >  static inline void send_unreach(struct sk_buff *skb_in, int code)
> >  {
> > +       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
> >         icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
> >  }
> >
> > @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
> >         .family         = AF_INET,
> >         .target         = reject,
> >         .targetsize     = sizeof(struct ipt_reject_info),
> > -       .table          = "filter",
> > -       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> > -                         (1 << NF_IP_LOCAL_OUT),
> >         .checkentry     = check,
> >         .me             = THIS_MODULE,
> >  };
>
> That includes an unrelated change, I meant to simply remove the filter
> table restriction.
>
> >>>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.
> >
> > 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 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.


Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 12:25       ` Al Boldi
@ 2007-10-12 12:31         ` Patrick McHardy
  2007-10-12 13:18           ` Al Boldi
  0 siblings, 1 reply; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12 12:31 UTC (permalink / raw)
  To: Al Boldi; +Cc: netfilter-devel, netdev, linux-kernel

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 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 little extra overhead.
If you really have to save resources, you should use PREROUTING/raw
to also avoid the creation of a connection tracking entry.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-11 21:31 [RFD] iptables: mangle table obsoletes filter table Al Boldi
  2007-10-12  4:35 ` Patrick McHardy
@ 2007-10-12 13:01 ` Jan Engelhardt
  2007-10-12 13:30   ` Al Boldi
  1 sibling, 1 reply; 25+ messages in thread
From: Jan Engelhardt @ 2007-10-12 13:01 UTC (permalink / raw)
  To: Al Boldi
  Cc: Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List, kaber


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&m=117394977210823&w=2
http://marc.info/?l=netfilter-devel&m=117400063907706&w=2

in the end, my proposal was something like
http://jengelh.hopto.org/GFX0/nf_proposal2.svg

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 12:31         ` Patrick McHardy
@ 2007-10-12 13:18           ` Al Boldi
  2007-10-12 13:23             ` Patrick McHardy
  0 siblings, 1 reply; 25+ messages in thread
From: Al Boldi @ 2007-10-12 13:18 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, netdev, linux-kernel

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 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 little extra overhead.
> If you really have to save resources, you should use PREROUTING/raw
> to also avoid the creation of a connection tracking entry.

Yes sure, if you use nat.  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 easily configurable as possible, and as things 
stand right now, the filter-table is completely useless for 99% of 
use-cases.


Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:18           ` Al Boldi
@ 2007-10-12 13:23             ` Patrick McHardy
  2007-10-12 22:56               ` Al Boldi
  0 siblings, 1 reply; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12 13:23 UTC (permalink / raw)
  To: Al Boldi; +Cc: netfilter-devel, netdev, linux-kernel

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 little extra overhead.
>>If you really have to save resources, you should use PREROUTING/raw
>>to also avoid the creation of a connection tracking entry.
> 
> 
> Yes sure, if you use nat.

Conntrack.

> 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 easily configurable as possible, and as things 
> stand right now, the filter-table is completely useless for 99% of 
> use-cases.


Sure, as I said, patches to remove the arbitary restrictions to
tables are welcome, but please do this for all targets and
matches which allow this, not only REJECT. And if you include a
seperate (tested) patch for the IPv4 and IPv6 REJECT targets
I'll consider it as well.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:01 ` Jan Engelhardt
@ 2007-10-12 13:30   ` Al Boldi
  2007-10-12 13:39     ` Jan Engelhardt
  0 siblings, 1 reply; 25+ messages in thread
From: Al Boldi @ 2007-10-12 13:30 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List, kaber

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&m=117394977210823&w=2
> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>
> in the end, my proposal was something like
> http://jengelh.hopto.org/GFX0/nf_proposal2.svg

Any chance you could publish this as something readable like text/html?


Thanks!

--
Al

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:30   ` Al Boldi
@ 2007-10-12 13:39     ` Jan Engelhardt
  2007-10-12 13:48       ` Patrick McHardy
  0 siblings, 1 reply; 25+ messages in thread
From: Jan Engelhardt @ 2007-10-12 13:39 UTC (permalink / raw)
  To: Al Boldi
  Cc: Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List, kaber


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&m=117394977210823&w=2
>> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>
>> in the end, my proposal was something like
>> http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>
>Any chance you could publish this as something readable like text/html?

Like, image/png?
http://jengelh.hopto.org/GFX0/nf_proposal2.png

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:39     ` Jan Engelhardt
@ 2007-10-12 13:48       ` Patrick McHardy
  2007-10-12 14:02         ` Jan Engelhardt
  2007-10-12 22:56         ` Al Boldi
  0 siblings, 2 replies; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12 13:48 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Al Boldi, Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List

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&m=117394977210823&w=2
>>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>>
>>>in the end, my proposal was something like
>>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>>
>>Any chance you could publish this as something readable like text/html?
> 
> 
> Like, image/png?
> http://jengelh.hopto.org/GFX0/nf_proposal2.png


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 possible to set up tables
basically any way you desire.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:48       ` Patrick McHardy
@ 2007-10-12 14:02         ` Jan Engelhardt
  2007-10-12 14:03           ` Patrick McHardy
  2007-10-12 22:56         ` Al Boldi
  1 sibling, 1 reply; 25+ messages in thread
From: Jan Engelhardt @ 2007-10-12 14:02 UTC (permalink / raw)
  To: Patrick McHardy
  Cc: Al Boldi, Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List


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 possible to set up tables
>basically any way you desire.

Will ebtables move a bit closer to iptables?


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 14:02         ` Jan Engelhardt
@ 2007-10-12 14:03           ` Patrick McHardy
  0 siblings, 0 replies; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12 14:03 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Al Boldi, Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List

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 (mangle/nat). So it should be possible to set up tables
>>basically any way you desire.
> 
> 
> Will ebtables move a bit closer to iptables?


I didn't get to that part yet, but yes, thats one of the goals.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:48       ` Patrick McHardy
  2007-10-12 14:02         ` Jan Engelhardt
@ 2007-10-12 22:56         ` Al Boldi
  2007-10-12 23:02           ` Patrick McHardy
  1 sibling, 1 reply; 25+ messages in thread
From: Al Boldi @ 2007-10-12 22:56 UTC (permalink / raw)
  To: Patrick McHardy, Jan Engelhardt
  Cc: Netfilter Developer Mailing List, netdev, linux-net,
	Linux Kernel Mailing List

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&m=117394977210823&w=2
> >>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
> >>>
> >>>in the end, my proposal was something like
> >>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
> >>
> >>Any chance you could publish this as something readable like text/html?
> >
> > Like, image/png?
> > http://jengelh.hopto.org/GFX0/nf_proposal2.png
>
> 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 possible to set up tables
> basically any way you desire.

Wow!  How soon can we expect this to surface on mainline?


Thanks a lot!

--
Al

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 13:23             ` Patrick McHardy
@ 2007-10-12 22:56               ` Al Boldi
  0 siblings, 0 replies; 25+ messages in thread
From: Al Boldi @ 2007-10-12 22:56 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, netdev, linux-kernel

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 easily configurable as possible, and as
> > things stand right now, the filter-table is completely useless for 99%
> > of use-cases.
>
> Sure, as I said, patches to remove the arbitary restrictions to
> tables are welcome, but please do this for all targets and
> matches which allow this, not only REJECT. And if you include a
> seperate (tested) patch for the IPv4 and IPv6 REJECT targets
> I'll consider it as well.

Sounds fair.  All we need now is for someone to kindly submit these rather 
straight forward patches.


Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12 22:56         ` Al Boldi
@ 2007-10-12 23:02           ` Patrick McHardy
  0 siblings, 0 replies; 25+ messages in thread
From: Patrick McHardy @ 2007-10-12 23:02 UTC (permalink / raw)
  To: Al Boldi
  Cc: Jan Engelhardt, Netfilter Developer Mailing List, netdev,
	linux-net, Linux Kernel Mailing List

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 possible to set up tables
>> basically any way you desire.
>>     
>
> Wow!  How soon can we expect this to surface on mainline?

I can't tell at this point, there's still too much work to do
for a realistic estimate. I'll post patches to netfilter-devel
as soon as its good enough for some real testing.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-12  5:37   ` Al Boldi
       [not found]     ` <470F5F19.70606@trash.net>
@ 2007-10-17 22:37     ` Bill Davidsen
  2007-10-17 23:24       ` Bill Davidsen
  1 sibling, 1 reply; 25+ messages in thread
From: Bill Davidsen @ 2007-10-17 22:37 UTC (permalink / raw)
  To: Al Boldi
  Cc: Patrick McHardy, netfilter-devel, netdev, linux-net, linux-kernel

Al Boldi wrote:
> Patrick McHardy wrote:
>> Please send mails discussing netfilter to netfilter-devel.
> 
> Ok.  I just found out this changed to vger.  But 
> netfilter-devel@vger.kernel.org is bouncing me.
> 
>> 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 differences in ordering (mangle comes before
>> DNAT, filter afterwards), but for most rulesets thats completely
>> irrelevant. The only difference that really matters is that mangle
>> performs rerouting in LOCAL_OUT for packets that had their routing
>> key changed, so its really a superset of the filter table. If you
>> want to use REJECT in the mangle table, you just need to remove the
>> restriction to filter, it works fine. I would prefer to also remove
>> the restriction of MARK, CONNMARK etc. to mangle, they're used for
>> more than just routing today so that restriction also doesn't make
>> much sense. Patches for this are welcome.
> 
> Something like this (untested):
> 
> --- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
> +++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
> @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
>  
>  static inline void send_unreach(struct sk_buff *skb_in, int code)
>  {
> +       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
>         icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
>  }
>  
> @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
>         .family         = AF_INET,
>         .target         = reject,
>         .targetsize     = sizeof(struct ipt_reject_info),
> -       .table          = "filter",
> -       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> -                         (1 << NF_IP_LOCAL_OUT),
>         .checkentry     = check,
>         .me             = THIS_MODULE,
>  };
> 
>>> 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 they need the prerouting chain to seal things.  Right now this is only 
> possible in the mangle table.
> 
I'm not sure what you think is unsafe about using the filter table, and 
the order of evaluation issues certainly seem to suggest that some 
actions would take a major rethink at least. Perhaps you could avoid 
breaking all of the setups which currently work, rather than force 
everyone to do things differently because you feel that your way is better.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-17 22:37     ` Bill Davidsen
@ 2007-10-17 23:24       ` Bill Davidsen
  2007-10-20  3:40         ` Al Boldi
  0 siblings, 1 reply; 25+ messages in thread
From: Bill Davidsen @ 2007-10-17 23:24 UTC (permalink / raw)
  To: Bill Davidsen
  Cc: Al Boldi, Patrick McHardy, netfilter-devel, netdev, linux-net,
	linux-kernel

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 they need the prerouting chain to seal things.  Right now 
>> this is only possible in the mangle table.
>>
> I'm not sure what you think is unsafe about using the filter table, and 
> the order of evaluation issues certainly seem to suggest that some 
> actions would take a major rethink at least. Perhaps you could avoid 
> breaking all of the setups which currently work, rather than force 
> everyone to do things differently because you feel that your way is better.
> 
It was my intention to suggest that unintentional breakage of existing 
setups should be avoided, not that removing the filter table was some 
evil plot. ;-)
On rereading my original post I failed to make that clear, please take 
it as intended.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables:  mangle table obsoletes filter table
  2007-10-17 23:24       ` Bill Davidsen
@ 2007-10-20  3:40         ` Al Boldi
  2007-10-20  4:47           ` Valdis.Kletnieks
  0 siblings, 1 reply; 25+ messages in thread
From: Al Boldi @ 2007-10-20  3:40 UTC (permalink / raw)
  To: Bill Davidsen
  Cc: Patrick McHardy, netfilter-devel, netdev, linux-net, linux-kernel

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 the filter table,
> >> when in fact they need the prerouting chain to seal things.  Right now
> >> this is only possible in the mangle table.
> >
> > I'm not sure what you think is unsafe about using the filter table, and
> > the order of evaluation issues certainly seem to suggest that some
> > actions would take a major rethink at least. Perhaps you could avoid
> > breaking all of the setups which currently work, rather than force
> > everyone to do things differently because you feel that your way is
> > better.
>
> It was my intention to suggest that unintentional breakage of existing
> setups should be avoided, not that removing the filter table was some
> evil plot. ;-)
> On rereading my original post I failed to make that clear, please take
> it as intended.

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 possible if we at least ported the REJECT target to mangle.


Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
  2007-10-20  3:40         ` Al Boldi
@ 2007-10-20  4:47           ` Valdis.Kletnieks
  2007-10-20 11:10             ` Jan Engelhardt
  2007-10-21  4:31             ` Al Boldi
  0 siblings, 2 replies; 25+ messages in thread
From: Valdis.Kletnieks @ 2007-10-20  4:47 UTC (permalink / raw)
  To: Al Boldi
  Cc: Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
	linux-net, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

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 possible if we at least ported the REJECT target to mangle.

That's *half* the battle.  The other half is explaining why I should move
from a perfectly functional setup that uses the filter table.  What gains
do I get from doing so?  What isn't working that I don't know about? etc?

In other words - why do I want to move from filter to mangle?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
  2007-10-20  4:47           ` Valdis.Kletnieks
@ 2007-10-20 11:10             ` Jan Engelhardt
  2007-10-21  4:31             ` Al Boldi
  1 sibling, 0 replies; 25+ messages in thread
From: Jan Engelhardt @ 2007-10-20 11:10 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Al Boldi, Bill Davidsen, Patrick McHardy, netfilter-devel,
	netdev, linux-net, linux-kernel


On Oct 20 2007 00:47, Valdis.Kletnieks@vt.edu 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 possible if we at least ported the REJECT target to mangle.
>
>That's *half* the battle.  The other half is explaining why I should move
>from a perfectly functional setup that uses the filter table.  What gains
>do I get from doing so?  What isn't working that I don't know about? etc?
>
>In other words - why do I want to move from filter to mangle?

Packet processing time.
Compare previous:
	packet goes through mangle, then is dropped in filter
Compare afterwards:
	packet is already dropped in mangle

=> less code to run through

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
  2007-10-20  4:47           ` Valdis.Kletnieks
  2007-10-20 11:10             ` Jan Engelhardt
@ 2007-10-21  4:31             ` Al Boldi
  2007-10-21  4:53               ` Valdis.Kletnieks
  2007-10-23 22:27               ` Bill Davidsen
  1 sibling, 2 replies; 25+ messages in thread
From: Al Boldi @ 2007-10-21  4:31 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
	linux-net, linux-kernel

Valdis.Kletnieks@vt.edu 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. 
> > But this would only be possible if we at least ported the REJECT target
> > to mangle.
>
> That's *half* the battle.  The other half is explaining why I should move
> from a perfectly functional setup that uses the filter table.  What gains
> do I get from doing so?  What isn't working that I don't know about? etc?
>
> In other words - why do I want to move from filter to mangle?

This has already been explained in this thread; here it is again:

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 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 gaping whole in your firewall, that 
could easily be exploited for DoS attacks at the least, unless you put in 
specific rules to limit this.

Plus, it's outrageously incorrect to accept invalid packets, just because 
your filtering infrastructure can only reject packets after they have been 
prerouted.


Thanks!

--
Al


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
  2007-10-21  4:31             ` Al Boldi
@ 2007-10-21  4:53               ` Valdis.Kletnieks
  2007-10-23 22:27               ` Bill Davidsen
  1 sibling, 0 replies; 25+ messages in thread
From: Valdis.Kletnieks @ 2007-10-21  4:53 UTC (permalink / raw)
  To: Al Boldi
  Cc: Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
	linux-net, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

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 gaping whole in your firewall, that 
> could easily be exploited for DoS attacks at the least, unless you put in 
> specific rules to limit this.

OK, the light bulb just went on... ;)

We actually *do* have an issue with the flip side of that - it's a frikking
pain to make packets that show up on eth0 with a destination of 127.0.0.1
go away un-noticed - or at least I'm assuming it's the flip side of the same
issue.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
  2007-10-21  4:31             ` Al Boldi
  2007-10-21  4:53               ` Valdis.Kletnieks
@ 2007-10-23 22:27               ` Bill Davidsen
  1 sibling, 0 replies; 25+ messages in thread
From: Bill Davidsen @ 2007-10-23 22:27 UTC (permalink / raw)
  To: Al Boldi
  Cc: Valdis.Kletnieks, Patrick McHardy, netfilter-devel, netdev,
	linux-net, linux-kernel

Al Boldi wrote:
> Valdis.Kletnieks@vt.edu 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. 
>>> But this would only be possible if we at least ported the REJECT target
>>> to mangle.
>> That's *half* the battle.  The other half is explaining why I should move
>> from a perfectly functional setup that uses the filter table.  What gains
>> do I get from doing so?  What isn't working that I don't know about? etc?
>>
>> In other words - why do I want to move from filter to mangle?
> 
> This has already been explained in this thread; here it is again:
> 
> 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 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 gaping whole in your firewall, that 
> could easily be exploited for DoS attacks at the least, unless you put in 
> specific rules to limit this.
> 
Well... true enough on a small firewall machine with a really fast link, 
maybe. I like your point about efficiency better, it's more logical, 
like putting an ACCEPT of established connections before a lot of low 
probability rules. The only time I have seen rules actually bog a 
machine was when a major ISP sent out a customer "upgrade" with a bug 
which caused certain connections to be SYN-SYN/ACK-RST leaving half open 
sockets. They sent out 160k of them and the blocking list became very 
long as blocking rules were added.

> Plus, it's outrageously incorrect to accept invalid packets, just because 
> your filtering infrastructure can only reject packets after they have been 
> prerouted.
> 
As long as the filter table doesn't go away, sometimes things change 
after PREROUTING, like NAT, and additional rules must be used.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [RFD] iptables: mangle table obsoletes filter table
       [not found] <200710120814.23903.a1426z@gawab.com>
@ 2007-10-18 15:41 ` Matthew Faulkner
  0 siblings, 0 replies; 25+ messages in thread
From: Matthew Faulkner @ 2007-10-18 15:41 UTC (permalink / raw)
  To: linux-kernel

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 packet sizes are greater than 524.

Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    MBytes  /s  % S      % S      us/KB   us/KB
 65536  65536    523    30.01        81.49   50.00    50.00    11.984  11.984
 65536  65536    524    30.01       460.61   49.99    49.99    2.120   2.120

The chances are i'm being stupid and there is an obvious reason for
this, but when i put  the server and client on different cores i don't
see this effect.

Any help explaining this will be greatly appreciated.

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2007-10-23 22:18 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-11 21:31 [RFD] iptables: mangle table obsoletes filter table Al Boldi
2007-10-12  4:35 ` Patrick McHardy
2007-10-12  5:37   ` Al Boldi
     [not found]     ` <470F5F19.70606@trash.net>
2007-10-12 12:25       ` Al Boldi
2007-10-12 12:31         ` Patrick McHardy
2007-10-12 13:18           ` Al Boldi
2007-10-12 13:23             ` Patrick McHardy
2007-10-12 22:56               ` Al Boldi
2007-10-17 22:37     ` Bill Davidsen
2007-10-17 23:24       ` Bill Davidsen
2007-10-20  3:40         ` Al Boldi
2007-10-20  4:47           ` Valdis.Kletnieks
2007-10-20 11:10             ` Jan Engelhardt
2007-10-21  4:31             ` Al Boldi
2007-10-21  4:53               ` Valdis.Kletnieks
2007-10-23 22:27               ` Bill Davidsen
2007-10-12 13:01 ` Jan Engelhardt
2007-10-12 13:30   ` Al Boldi
2007-10-12 13:39     ` Jan Engelhardt
2007-10-12 13:48       ` Patrick McHardy
2007-10-12 14:02         ` Jan Engelhardt
2007-10-12 14:03           ` Patrick McHardy
2007-10-12 22:56         ` Al Boldi
2007-10-12 23:02           ` Patrick McHardy
     [not found] <200710120814.23903.a1426z@gawab.com>
2007-10-18 15:41 ` Matthew Faulkner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).