Re: let nftables indicate incomplete dissections

[Phil Sutter <phil@nwl.cc>]

Hi!

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.
> 
> 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.

ACK, we'll certainly end up in a similar situation as with iptables-nft
so doing nothing is not an option.

> 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.
> 
> 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.

The JSON interface prefixes dumps by a metainfo object which holds nft
version number and a schema version (still "1"). Introducing a similar
"bytecode versioning" cached in and dumped by kernel space might be a
quick way to enable a current nft tool to detect a bytecode from the
future, assuming that we'll also take care and increment that version
when things change. 

OTOH, considering compatibility (or testing for it somehow) of a given
bytecode change may be much more tedious than a practical approach of
trying to parse and using a defined exit when failing.

Cheers, Phil