Re: [RFC libnftnl/nft 0/5] nftables: indicate presence of unsupported netlink attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 16, 2024 at 07:07:24PM +0200, Phil Sutter wrote:
> On Mon, Oct 07, 2024 at 11:49:33AM +0200, Florian Westphal wrote:
> [...]
> > Extend libnftnl to also make an annotation when a known expression has
> > an unknown attribute included in the dump, then extend nftables to also
> > display this to the user.
> 
> We must be careful with this and LIBVERSION updates. I'm looking at
> libnftnl-1.2.0 which gained support for NFTA_TABLE_OWNER,
> NFTA_SOCKET_LEVEL, etc. but did not update LIBVERSION at all - OK,
> that's probably a bug. But there is also libnftnl-1.1.9 with similar
> additions (NFTA_{DYNSET,SET,SET_ELEM}_EXPRESSIONS) and a LIBVERSION
> update in the compatible range (15:0:4 -> 16:0:5).

LIBVERSION talks about libnftnl API, not netlink attributes?
Probably 1.1.9 got any API update while 1.20 did not?

> We may increase incomplete marker correctness by treating support for
> any new attribute an incompatible update. Given that we often have
> dependencies between libnftnl and nftables for other things, it may not
> be too much of a downside though.

15:0:4 -> 16:0:5 means new API is available while older are still
supported, so old nftables can use this library binary safely.

You mean, we should reset age, considering c:0:a?

> > Debug out out will include the [incomplete] tag for each affected
> > expression.
> 
> Looking at the impact this series has for such situations, I want to
> make the iptables-nft compat extension stuff depend on it for better
> detection of incompatible rule content.
> 
> Thanks, Phil
> 




[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux