On Wed, Jun 12, 2024 at 09:50:13AM +0200, Florian Westphal wrote: > "nft list ruleset" currently omits things it does not understand > and that it cannot represent in any other way. > > This includes: > 1. expression is unknown > 2. expression is known (e.g. "cmp"), but attr contains unexpected value > 3. expression is known but there is an unknown netlink attr contained in > the dump > > 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? > This is mainly needed for container environments, where host environment > might be using a lot older version than what is used by a specific > container image. > > 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). - Use a netlink representation as raw expression: meta@1,3,0x0x000000004 but this requires dumping the whole list of attributes which is chatty. Or explore a combination of both. 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. > 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"?
