Am 04.05.2020 14:45, schrieb Pablo Neira Ayuso:
On Fri, May 01, 2020 at 10:59:15PM +0200, Michael Braun wrote:
This enables commands like
nft set bridge t s4 '{typeof vlan id . ip daddr; elements = { 3567 .
1.2.3.4 }; }'
Which would previously fail with
Error: can not use variable sized data types (integer) in concat
expressions
Now that typeof is in place, the integer_type can be set to 32-bits
(word size).
When just changing the datatype definition of integer_type to .size =
32,
the resulting set elements are broken:
# ether type vlan @ll,112,16 & 4095 . ip daddr { 4095 . 1.0.0.1} accept
__set%d test-bridge 3 size 1
__set%d test-bridge 0
element ff0f0000 01000001 : 0 [end]
bridge
[ payload load 2b @ link header + 12 => reg 1 ]
[ cmp eq reg 1 0x00000081 ]
[ payload load 2b @ link header + 16 => reg 1 ]
[ cmp eq reg 1 0x00000008 ]
[ payload load 2b @ link header + 14 => reg 1 ]
[ bitwise reg 1 = (reg=1 & 0x0000ff0f ) ^ 0x00000000 ]
[ payload load 4b @ network header + 16 => reg 9 ]
[ lookup reg 1 set __set%d ]
[ immediate reg 0 accept ]
I also verified that such a rule really does not match
ether type vlan id . ip daddr { 501 . 141.24.44.2 } log
prefix "trace "
vlan id 501 ip daddr 141.24.44.2 log prefix "trace2
Results in dmesg entries only for trace2.
Whereas it worked with my last version.
I cannot really find the place to fix this. Any hint?
I would prefer to not expose the integer type definition to sets:
+ set s4 {
+ type integer . ipv4_addr
+ elements = { 0 . 13.239.0.0 }
+ }
+
Users do not need to know that an 8-bit payload field is actually
aligned to 32-bits. Or that osf name is actually and 32-bit id number.
That was already fixed with e10356a4 ("tests: dump generated use new nft
tool").
Regards,
M. Braun
