On Sun, Jul 17, 2016 at 12:41:59PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pa...@netfilter.org> wrote:
> > On Sat, Jul 16, 2016 at 08:12:51PM +0200, Florian Westphal wrote:
> > > Pablo Neira Ayuso <pa...@netfilter.org> wrote:
> > > > On Sat, Jul 16, 2016 at 04:51:30PM +0200, Pablo Neira Ayuso wrote:
> > > > > On Sat, Jul 16, 2016 at 06:42:24PM +0800, Liping Zhang wrote:
> > > > > > # iptables-translate -A INPUT -m connlabel ! --label bit40 --set
> > > > > > nft add rule ip filter INPUT ct label set bit40 ct label and
> > > > > > bit40 != bit40 counter
> > > > >
> > > > > I think this logic is inverted, I mean:
> > > > >
> > > > > nft add rule ip filter INPUT ct label and bit40 != bit40 ct label set
> > > > > bit40 counter
> > > > > ---------------------------
> > > > >
> > > > > test should happen before set.
> > > >
> > > > BTW, why not simply translate this to:
> > > >
> > > > nft add rule ip filter INPUT ct label set bit40 counter
> > >
> > > Its not the same as the bloated version.
> > >
> > > The set operation will only ever fail in case the conntrack doesn't have
> > > a label
> > >
> > > extension or is untracked/invalid, but if that is the case we get
> > > different results:
> > >
> > > nft add rule ip filter INPUT ct label set bit40 ct label and bit40 !=
> > > bit40 counter
> > >
> > > -> counter Increments for every packet that lacks a conntrack, or the
> > > conntrack extension
> > >
> > > nft add rule ip filter INPUT ct label set bit40 counter
> > >
> > > -> counter Increments for every packet (we don't set NFT_BREAK anywhere
> > > in the setter).
>
> > set operations are not expected to return anything at all, they must
> > always evaluate true.
>
> Yes.
>
> > This behaviour is deviating from what we have in other set operations,
> > this is clearly inconsistent.
>
> How so?
So this is there just to cover the fail the ENOSPC when setting label?
This internal behaviour in xt connlabel seems confusing to me, this
rule:
iptables -A INPUT -m connlabel ! --label bit40 --set
following the reading from left to right convention tells me:
if not bit40 set, then set it.
But this is actually setting in first place inconditionally, then
checking this is not set, what is the use case for this?
Actually the kernel code first sets the bit, then checks if this is
unset for this. Note iptables-save displays this in that way as
output.
You can probably introduce in iptables something like:
iptables -A INPUT -m connlabel --set-label bit40
that we can naturally map to nftables for newcomers using this, as
well as less expensive.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
