Shaun Brady <brady.1345@xxxxxxxxx> wrote:
> I'm sure I bit off more than I could chew, but I attempted to write a proof of
> concept patch to add a new set type, inet_addr, which would allow elements of
> both ipv4_addr and ipv6_addr types.
Why? This is hard, the kernel has no notion of data types.
> Something to the tune of:
>
> nft add set inet filter set_inet {type inet_addr\;}
> nft add element inet filter set_inet { 10.0.1.195, 10.0.1.200, 10.0.1.201, 2001:db8::8a2e:370:7334 }
How would this work with ranges or concatenations?
> Figuring most of this would be implemented in the nft userland, I started
> there, and was able to successfully get a new set type that allowed v4
> addresses OR v6 addresses, depending on how I defined the datasize of
> inet_addr (4 bytes or 16 bytes).
>
> When leaving inet_addr size at the required (for both v4 and v6) 16 bytes
> netlink would return EINVAL when adding v4 addresses to the set. We found in
> nft_value_init:
>
> if (len != desc->len)
> return -EINVAL;
>
> with len being the nlattr (the v4 address) and desc being the nft_set_desc. 4 != 16.
> My questions:
>
> 1) Is this feature interesting enough to pursue (given what would have to be
> done to make it work (see next question))? The set type only makes sense in
> inet tables (I think...) and even then, would roughly be syntactic sugar for
> what could be done (more efficiently) with two sets of the base protocols. But
> hey, nice things make nice tools?
I don't see how its doable. The lookup key fed to the set lookup
function via nft_lookup.c has a fixed size.
