Re: [RFC] concat with dynamically sized fields like vlan id

[michael-dev <michael-dev@fami-braun.de>]

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