Re: [RFC PATCH nft userspace] nft: connlabel matching support

[Florian Westphal <fw@strlen.de>]

Patrick McHardy <kaber@trash.net> wrote:
> Ok I misunderstood your initial problem statement. So basically what it
> should currently do:
> 
> ct labels foo => test whether that bit is set
> ct labels == foo => test whether foo and only foo is set
> 
> Ok I can see the problem :)
> 
> The implicit op only selects FLAGCMP for EXPR_LIST (see
> expr_evaluate_relational()). That should probably be changed to take the
> base type into account. This also seems wrong for the ct state expression,
> we currently use equality if only one state is specified but use a flag
> comparison if multiple flags are specified.

I hacked something up to also select FLAGCMP for bitmask type.

$ nft --debug=netlink add rule filter output ct labels foo
ip filter output 0 0
 [ ct load labels => reg 1 ]
 [ bitwise reg 1 = (reg=1 & 0x00000001 0x00000000 0x00000000 0x00000000 ) ^ 0x00000000 0x00000000 0x00000000 0x00000000 ]
 [ cmp neq reg 1 0x00000001 0x00000000 0x00000000 0x00000000 ]

looks better.  Still not exactly the same though.
The cmp neq will cause it to match when the label is not set.

I then tried again with vanilla master branch:
tcp flags syn counter packets 0 bytes 0
tcp flags fin,syn counter packets 184 bytes 24880

So, same problem there: EXPR_LIST == cmp neq.  Is that intentional?
It seems wrong to me, e.g.  "tcp flags fin,syn" will match virtually all
tcp packets.

Maybe netlink_gen_flagcmp() should generate NFT_CMP_GT i.e.:
 [ bitwise reg 1 = (reg=1 & 0x00000012 ) ^ 0x00000000 ]
 [ cmp gt reg 1 0x00000000 ]

At least that would be what I would have expected :-}

Am I wrong?
As a side note, experimenting a bit with tcp flags:

add rule filter output tcp flags & (syn|ack) == (syn|ack)

works fine with current master branch.  But list shows

"tcp flags & 18 == 18", i.e. no symbol translation.

Shouldn't it restore the symbolic names?
I think this is the very same problem that I had with my connlabel
dabbling, so it would be nice if it could be solved in generic way.

Thanks,
Florian