From: Florian Westphal <fw@strlen.de>
To: Patrick McHardy <kaber@trash.net>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft] parser: support reject unreach|reset
Date: Tue, 4 Mar 2014 10:03:07 +0100 [thread overview]
Message-ID: <20140304090307.GK9965@breakpoint.cc> (raw)
In-Reply-To: <20140304085029.GC5094@macbook.localnet>
Patrick McHardy <kaber@trash.net> wrote:
> On Mon, Mar 03, 2014 at 10:12:26PM +0100, Florian Westphal wrote:
> > reject did not allow to use tcp reset instead of icmp unreach.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> > After this patch its possibe to do something like
> >
> > rule filter output reject reset
>
> Actually this looks a lot like "iptables thinking" :)
*ahem* :)
> Why not simply use "reset" as keyword?
Yes, that would work as well.
> > Which makes kernel generate bogus tcp resets in repsonse
> > to non-tcp packets.
> >
> > In iptables this is avoided by making checkentry fail if -p tcp is not
> > specified when tcp-reset is requested.
> >
> > How should this be handled in nft?
>
> We could either add some infrastructure to the kernel to mimic the iptables
> check, add runtime fallback to ICMP for non-TCP packets or simply ignore them.
>
> It shouldn't be difficult to check within the rule for the required matches,
> however I'm not so sure this is really the way to go since it precludes
> optimizations that spawn over multiple rules, f.i. checking for TCP before
> a chain jump and have only TCP-specific rules in that chain.
Good point.
> I'm tending towards simply ignoring non-TCP packets at runtime.
Eric, please let me know if you want to address all of this in your icmp
code patch series, or if you would like me to handle this.
If you want me to handle it I will resubmit this patch with the issues
pointed out by Patrick resolved, plus a small kernel patch to not xmit
reset for non-tcp packets.
Otherwise I'll just mark this patch as "rejected" in patchwork.
> > %token _REJECT "reject"
> > +%token REJECT_RESET "reset"
> > +%token REJECT_UNREACH "unreach"
>
> Please don't use expression/statement-specific token names. We're simply
> dealing with tokens, how they're used depends on the remaining grammar.
Makes sense.
Thanks for your help Patrick.
prev parent reply other threads:[~2014-03-04 9:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 21:12 [PATCH nft] parser: support reject unreach|reset Florian Westphal
2014-03-03 21:41 ` Eric Leblond
2014-03-03 22:03 ` Florian Westphal
2014-03-04 9:08 ` Patrick McHardy
2014-03-04 9:01 ` Patrick McHardy
2014-03-04 8:50 ` Patrick McHardy
2014-03-04 9:03 ` Florian Westphal [this message]
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=20140304090307.GK9965@breakpoint.cc \
--to=fw@strlen.de \
--cc=kaber@trash.net \
--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).