From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Tom Yan <tom.ty89@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 2/3] netlink_linearize: incorrect netlink bytecode with binary operation and flags
Date: Thu, 29 Jul 2021 08:55:46 +0200 [thread overview]
Message-ID: <20210729065546.GA15962@salvia> (raw)
In-Reply-To: <CAGnHSEnxcVjN2etN-LNCgpb1h_hmSWMMh3Zm-GqbkZ0XOxCN-w@mail.gmail.com>
On Thu, Jul 29, 2021 at 10:57:35AM +0800, Tom Yan wrote:
> On Wed, 28 Jul 2021 at 05:05, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > A quick summary:
> >
> > - If you want an exact match:
> >
> > tcp flags == fin,syn,ack
> >
> > - If you want to check that those three bits are set on (regardless
> > the remaining bits):
> >
> > tcp flags fin,syn,ack / fin,syn,ack
> >
> > - If you want to check that any of these three bits is set on:
> >
> > tcp flags fin,syn,ack
>
> This is exactly what I find absurd btw. IMHO it's much better if the
> latter just means `tcp flags == (fin | syn | ack)`.
Look at this from a different angle, ie. ct state
ct state new,established
ct state also has a bitmask datatype, and people are not expecting
here to match to new AND established.
> I'd rather we keep `tcp flags & (fin | syn | ack) != 0` and so
> "unsimplified" or accept something like `tcp flags { fin / fin, syn
> / syn, ack / ack }`
The curly brace notation implies the use of sets. Sets only allow for
exact matches, therefore
tcp flags { fin, syn, ack}
is actually making exact matches on the tcp flags.
next prev parent reply other threads:[~2021-07-29 6:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 15:37 [PATCH nft 1/3] expression: missing != in flagcmp expression print function Pablo Neira Ayuso
2021-07-27 15:37 ` [PATCH nft 2/3] netlink_linearize: incorrect netlink bytecode with binary operation and flags Pablo Neira Ayuso
2021-07-27 18:36 ` Tom Yan
2021-07-27 21:05 ` Pablo Neira Ayuso
2021-07-29 1:48 ` Tom Yan
2021-07-29 7:03 ` Pablo Neira Ayuso
2021-07-29 10:41 ` Tom Yan
2021-07-29 10:58 ` Tom Yan
2021-07-29 15:16 ` Tom Yan
2021-07-30 4:53 ` Tom Yan
2021-07-29 2:57 ` Tom Yan
2021-07-29 6:55 ` Pablo Neira Ayuso [this message]
2021-07-27 15:37 ` [PATCH nft 3/3] evaluate: disallow negation with binary operation Pablo Neira Ayuso
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=20210729065546.GA15962@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=tom.ty89@gmail.com \
/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.