From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: [iptables PATCH] nft: Optimize class-based IP prefix matches
Date: Tue, 6 Oct 2020 11:41:21 +0200 [thread overview]
Message-ID: <20201006094121.GA17201@salvia> (raw)
In-Reply-To: <20201006093744.GL29050@orbyte.nwl.cc>
On Tue, Oct 06, 2020 at 11:37:44AM +0200, Phil Sutter wrote:
> On Tue, Oct 06, 2020 at 10:56:21AM +0200, Pablo Neira Ayuso wrote:
> > On Fri, Oct 02, 2020 at 11:03:34AM +0200, Phil Sutter wrote:
> > > Payload expression works on byte-boundaries, leverage this with suitable
> > > prefix lengths.
> >
> > Interesing. But it kicks in the raw payload expression in nftables.
> >
> > # nft list ruleset
> > table ip filter {
> > chain INPUT {
> > type filter hook input priority filter; policy accept;
> > @nh,96,24 8323072 counter packets 0 bytes 0
> > }
> >
> > Would you send a patch for nftables too? There is already approximate
> > offset matching in the tree, it should not be too hard to amend.
>
> I had a quick look but it didn't seem trivial to me. It is in
> payload_expr_complete() where a template lookup happens based on
> expression offset and length which fails due to the unexpected length.
> Is this the right place to adjust or am I wrong?
>
> Strictly speaking, this is just a lack of feature in nftables and
> nothing breaks due to it. Do you still want to block the iptables change
> for it?
Not block. Just get things aligned. This is a bit of a step back in
the integration between iptables-nft and nft IMO.
I will have a look.
next prev parent reply other threads:[~2020-10-06 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 9:03 [iptables PATCH] nft: Optimize class-based IP prefix matches Phil Sutter
2020-10-02 11:25 ` Arturo Borrero Gonzalez
2020-10-02 11:34 ` Phil Sutter
2020-10-06 8:56 ` Pablo Neira Ayuso
2020-10-06 9:37 ` Phil Sutter
2020-10-06 9:41 ` Pablo Neira Ayuso [this message]
2020-10-06 11:48 ` Phil Sutter
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=20201006094121.GA17201@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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.