Patrick McHardy <kaber@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html