mark set datatype check too strict?

mark set datatype check too strict?

[Florian Westphal]

Hello Patrick

last your you added check to make this illegal:

nft add rule ip filter input ip daddr 192.168.7.1 meta mark set '(ip saddr & 0xff)'
datatype mismatch: expected packet mark, expression has type IPv4 address

My question is -- why?
The changelog for 068e138a8d9eb doesn't say :)
Doesn't that take away a lot of flexibility?

For instance one could e.g. set conntrack zones based on the VLAN id:

bridge ... prerouting ct zone set vlan id
(yes, I know that zone cannot be set at the moment).

'nft add rule bridge filter prerouting meta mark set vlan id'
should work, in my opinion.  Any ideas/comments?

In case its relevant: I'm working on bridge defrag+conntrack, and one
of the open questions is handling of vlan identifiers
so that we can deal with overlapping addresses in different VLANs.

Since it might be feasible to allow tracking inside other encap
protocols (e.g. pppoe) at one point I would prefer to handle isolation
via conntrack zones since thats already available and not have
to deal with vlan identifiers directly in the kernel.

But if doing operations like 'set zone based on vlan id' is illegal/
considered bad I will have to reconsider...

Thanks!

Re: mark set datatype check too strict?

[Pablo Neira Ayuso]

Hi Florian,

On Wed, Jan 20, 2016 at 05:31:24PM +0100, Florian Westphal wrote:
> Hello Patrick
> 
> last your you added check to make this illegal:
> 
> nft add rule ip filter input ip daddr 192.168.7.1 meta mark set '(ip saddr & 0xff)'
> datatype mismatch: expected packet mark, expression has type IPv4 address
> 
> My question is -- why?
> The changelog for 068e138a8d9eb doesn't say :)
> Doesn't that take away a lot of flexibility?
> 
> For instance one could e.g. set conntrack zones based on the VLAN id:
> 
> bridge ... prerouting ct zone set vlan id
> (yes, I know that zone cannot be set at the moment).
> 
> 'nft add rule bridge filter prerouting meta mark set vlan id'
> should work, in my opinion.  Any ideas/comments?

Last time we talked about this, Patrick mentioned about adding
explicit casting. We definitely want this flexibility.