From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Netfilter Developer Mailing List
<netfilter-devel@lists.netfilter.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xt_request_find_match
Date: Tue, 19 Dec 2006 14:28:58 +0100 [thread overview]
Message-ID: <4587E91A.2020903@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0612191405160.24179@yvahk01.tjqt.qr>
Jan Engelhardt wrote:
> On Dec 19 2006 12:51, Patrick McHardy wrote:
>
>>>Reusing code is a good idea, and I would like to do so from my
>>>match modules. netfilter already provides a xt_request_find_target() but
>>>an xt_request_find_match() does not yet exist. This patch adds it.
>>
>>Why does your match module needs to lookup other matches?
>
>
> To use them?
>
> I did not want to write
>
>
> some_xt_target() {
> if(skb->nh.iph->protocol == IPPROTO_TCP)
> do_this();
> else
> do_that();
> }
I don't think
xt_request_find_match(match->family, "tcp", 0)->match(lots of arguments)
is better than a simple comparison. Besides that the tcp match itself
expects that the protocol match already checked for IPPROTO_TCP, so
you'd still have to do it.
> since the xt_tcpudp module provides far more checks than just the protocol
> (TCP/UDP), like
>
> /* To quote Alan:
>
> Don't allow a fragment of TCP 8 bytes in. Nobody normal
> causes this. Its a cracker trying to break in by doing a
> flag overwrite to pass the direction checks.
> */
This check makes sure the flags are not overwritten _after you
matched on them_. It doesn't matter at all if you're only
interested in the protocol since the user didn't tell you to care.
next prev parent reply other threads:[~2006-12-19 13:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-16 17:55 [PATCH] xt_request_find_match Jan Engelhardt
2006-12-19 11:51 ` Patrick McHardy
2006-12-19 13:07 ` Jan Engelhardt
2006-12-19 13:28 ` Patrick McHardy [this message]
2006-12-19 15:27 ` Jan Engelhardt
2006-12-20 8:16 ` Patrick McHardy
2006-12-20 9:11 ` Jan Engelhardt
2006-12-20 9:17 ` Patrick McHardy
2006-12-23 21:57 ` xt_request_find_match Jan Engelhardt
2007-01-09 10:44 ` xt_request_find_match Patrick McHardy
2007-01-09 21:44 ` xt_request_find_match Jan Engelhardt
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=4587E91A.2020903@trash.net \
--to=kaber@trash.net \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.