Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > If backend (libnftl) could mark expressions as incomplete (from .parse > > callbacks?), it would be then possible for the frontend (nft) to document > > this, e.g. by adding something like "# unknown attributes", or similar. > > ack, how do you plan to handle this? 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. > > 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. > Or explore a combination of both. Right. > I am telling all this because I suspect maybe this "forward > compatibility" (a.k.a. "old tools support the future") could rise the > bar again and have a requirement to be able to load rulesets that > contains features that old tools don't understand. Well, I don't think we can do that. Perhaps with a new tool that allows to assemble raw expressions, but I'm not sure its worth extending nft for this, the parser (and grammar) is already huge. > > If noone has any objections, I would place this on my todo list and > > start with adding to libnftnl the needed "expression is incomplete" > > marking by extending the .parse callbacks. > > Maybe it is worth exploring what I propose above instead of displaying > "expression is incomplete"? For cases where libnftnl is fine but nft lacks a human-readable name I think such @meta,42 would be fine. But I don't think its good to allow decoding something arbitary, I think we would have to acknowledge that this can't be done unless you have a textual parser for raw netlink descriptions (i.e., full/unreadable TLV soup).
