From: Bill Davidsen <davidsen@tmr.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Patrick McHardy <kaber@trash.net>,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
linux-net@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFD] iptables: mangle table obsoletes filter table
Date: Wed, 17 Oct 2007 18:37:21 -0400 [thread overview]
Message-ID: <47168EA1.1080300@tmr.com> (raw)
In-Reply-To: <200710120837.18152.a1426z@gawab.com>
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
next prev parent reply other threads:[~2007-10-17 22:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200710120031.42805.a1426z@gawab.com>
[not found] ` <470EF994.4080403@trash.net>
2007-10-12 4:39 ` [RFD] iptables: mangle table obsoletes filter table Patrick McHardy
2007-10-12 5:37 ` Al Boldi
2007-10-12 11:48 ` Patrick McHardy
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 [this message]
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
2007-10-12 5:14 Al Boldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47168EA1.1080300@tmr.com \
--to=davidsen@tmr.com \
--cc=a1426z@gawab.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).