Feedback on variable sized set elements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

This email is mostly for education purposes.

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.

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 }

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?


2) (assuming #1) I believe we would have to put a condition to check the set
type versus the nlattr type, and allow a size difference on
set(inet_addr)/set_elem(ipv4_addr) (I don't know if that has any
ramifications).

I found set.ktype, but that is indicated to be unused in the kernel, and
comes from userland any way, so I don't believe it can be reliably used
to map to a set type.

Another possible approach would be to create an API to transmit valid size
types for a set type from userland. We would still need to ID the set type,
and that has the above problems of set.ktype.

Do either of these approaches make sense and secondly do either seem tenable?
Are there other obvious paths forward to deal with variable set element sizes?


Thanks!


SB




[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux