RFD - Exposing netfilter types?

RFD - Exposing netfilter types?

[Ian Pilcher]

Recently, I asked what I thought would be a simple question.  How should
an application go about determining the type of objects stored in an
nftables set.

   https://marc.info/?l=netfilter&m=176546062431223&w=2

As seen in the response (thanks Florian!), doing this for all possible
types, including concatenations, is actually pretty complicated.

Presumably, this is why the NFTA_SET_KEY_TYPE values that correspond to
simple types aren't in any public header.  Instead, those values, along
with all of the logic associated with complex types seem to exist solely
within the nftables user-space utility (nft).

Of course, this presents a problem for any other application that wants
to work with these types/values.  Today, any such program needs to copy
the values and/or logic that it needs from the nft sources.

Is there any reason that the type-related stuff that's currently in nft
shouldn't be broken out into a separate library that other applications
could also use?

(Or have I missed something glaringly obvious.  That's always a
possibility.)

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================

Re: RFD - Exposing netfilter types?

[Florian Westphal]

Ian Pilcher <arequipeno@gmail.com> wrote:
> Recently, I asked what I thought would be a simple question.  How should
> an application go about determining the type of objects stored in an
> nftables set.
> 
>   https://marc.info/?l=netfilter&m=176546062431223&w=2
> 
> As seen in the response (thanks Florian!), doing this for all possible
> types, including concatenations, is actually pretty complicated.
> 
> Presumably, this is why the NFTA_SET_KEY_TYPE values that correspond to
> simple types aren't in any public header.  Instead, those values, along
> with all of the logic associated with complex types seem to exist solely
> within the nftables user-space utility (nft).

Yes.  Note that the type info is only used for formatting the data.
Its not used by the kernel and its not relevant for matching.

Theoretically nft could store that data on disk and not even
send it to the kernel.

> Of course, this presents a problem for any other application that wants
> to work with these types/values.  Today, any such program needs to copy
> the values and/or logic that it needs from the nft sources.

Yes.

> Is there any reason that the type-related stuff that's currently in nft
> shouldn't be broken out into a separate library that other applications
> could also use?

Whats the use case?

Re: RFD - Exposing netfilter types?

[Ian Pilcher]

On 12/15/25 3:43 PM, Florian Westphal wrote:
> Ian Pilcher <arequipeno@gmail.com> wrote:
>> Recently, I asked what I thought would be a simple question.  How should
>> Presumably, this is why the NFTA_SET_KEY_TYPE values that correspond to
>> simple types aren't in any public header.  Instead, those values, along
>> with all of the logic associated with complex types seem to exist solely
>> within the nftables user-space utility (nft).
> 
> Yes.  Note that the type info is only used for formatting the data.
> Its not used by the kernel and its not relevant for matching.

Yup.  I understand that this is totally a user-space/informational
thing.

>> Is there any reason that the type-related stuff that's currently in nft
>> shouldn't be broken out into a separate library that other applications
>> could also use?
> 
> Whats the use case?

My immediate use case is really simple.  I just want to verify that a
set (identified type table & name) holds either IPv4 or IPv6 addresses.
Obviously, there's no need for a library for this, as I only need the
values of TYPE_IPADDR and TYPE_IP6ADDR.

For more complicated uses, it actually looks like libnftables can be
used.  (I was not aware that the nftables package actually includes a
shared library until I stumbled on it just now.)  I will say that it
might be nice to have an API that doesn't require using the JSON
interface, for programs that are using the netlink inteface more
directly (e.g. via libnftnl).

Overall, however, it looks like libnftables basically addresses the use
cases that I was thinking of.

Thanks!

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================