Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Add a "bool incomplete" to libnftnl strnct nftnl_expr, then set it > > from each expr->parse callback if there is a new netlink attribute that > > we did not understand. > > > > nft then checks if this is incomplete-marker is set. > > Is this sufficient? There are attribute values that could have an > unknown/unsupported value, eg. exthdr type (assuming a new extension > is supported). No, but libnftnl can't known (and should not care) if nftables can eat the value provided. i.e., 'incomplete' means 'there were attributes that I did not understand', nothing more. > I am afraid setting incomplete for an unknown attribute also restricts > netlink extensibility. How so? > Netlink allows for adding new attributes. Attributes also determine > semantics, eg. exthdr type restricts the semantics of other existing > attributes. There are also flags attributes which provide a hint on > what is support or not, toggling such flag allows kernel to reject > something that is not support. But thats up to higher level tool, i.e. nftables? I don't think libnftnl should try to guess if nftables can make sense of the rule provided (or set, element, etc). > > > > Related problem: entity that is using the raw netlink interface, it > > > > that case libnftnl might be able to parse everything but nft could > > > > lack the ability to properly print this. > > > > > > There are two options here: > > > > > > - Add more raw expressions and dump them, eg. meta@15, where 15 is the type. > > > This is more compact. If there is a requirement to allow to restore > > > this from older nftables versions, then it might be not enough since > > > maybe there is a need for meta@type,somethingelse (as in the ct direction > > > case). > > > > Yes, for attributes that libnftnl knows about but where nft lacks a name > > mapping (i.e., we can decode its META_KEY 0x42 but we have no idea what > > that means we could in fact add such a representation scheme. > > > > > - Use a netlink representation as raw expression: meta@1,3,0x0x000000004 > > > but this requires dumping the whole list of attributes which is chatty. > > > > Yes. Perhaps its better to consider adding a new tool (script?) that > > can dump the netlink soup without interpretation. IIRC libmnl debug > > already provides this functionality. > > > > Very chatty but it would be good enough to figure out what such > > hypothetical raw client did. > > I see, a binary netlink dump format. Yes, kinda like objump/readelf.
