On Wed, Sep 13, 2017 at 05:27:28PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Tue, Sep 12, 2017 at 07:25:27PM +0200, Florian Westphal wrote: > > > I am looking into adding 'string' type for sets. > > > To do this I'd need to add the typeof command that you mentioned > > > last year: > > > https://marc.info/?l=netfilter-devel&m=145683813130409&w=2 > > [..] > > > Missing part is to add a UDATA_SET_TYPEOF to store the original > > datatype. So, we dumping back the ruleset, we get same listing. > > Wait, so > nft add set ip filter set1 { typeof ip saddr;} > > then it should not list > nft add set ip filter set1 { type ipv4_addr;} > > but the exact input using the typeof()? > > I wonder how to encode this, especially given we also need to support > concatenation, e.g. > > nft add set ip f s { type ipv4_addr . typeof meta iifname . typeof tcp dport ;} > > > See UDATA_SET_KEYBYTEORDER and UDATA_SET_DATABYTEORDER for instance. > > They don't need to store a vector. These UDATA_SET_KEYBYTEORDER and UDATA_SET_DATABYTEORDER should be split not to store a vector anymore. We should have one UDATA_SET_KEYBYTEORDERX for each component of the tuple. > For the above we'd need to store the exact text input string to rebuild > cmdline. > > I think this needs to store something like this in the kernel: > ":4-meta iifname:16-tcp dport:2'. > > and nft needs to chew through this to learn the typeof and the size of > the datatype. > > Alternatively we need infra in nft to obtain the template that > was used to derive the size from the input string ("meta iifname"). > > I guess the latter should also be doable. If we do this then we'd > only need to store something like "-meta iifname-tcp dport" to help > with splitting the key into its components. > > > > meta mark set typeof(meta mark) ip saddr > > > > Casting is something we should definitely explore, yes. Question here > > is that we would need to annotate somewhere that the user has > > specified typeof(), or any cast, so we dump back exactly what the user > > is asking for. Probably this needs userdata area for expressions. > > Yes, seems like above needs to annotate payload expression (ip saddr) > with the typecast info. Alternatively however this MIGHT be able to > be detectable on userspace side, e.g. > > meta mark set ip saddr > > We know that meta mark wants the packet mark, so we could infer > that user forced an override of the type mismatch, and that can > be determined by looking at the expressions' data type. That's another possibility, yes. I would start with typeof() support for set, then we look at casting. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
