Re: [nf-next PATCH] netfilter: nfnetlink_hook: Dump nat type chains

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Mar 19, 2026 at 10:08:30PM +0100, Phil Sutter wrote:
> On Thu, Mar 19, 2026 at 06:06:10PM +0100, Florian Westphal wrote:
> > Phil Sutter <phil@nwl.cc> wrote:
> > > Ah, so the nat-type chain's priority value orders it inside the
> > > dispatcher's list.
> > 
> > Yes.
> > 
> > > Maybe I should print them below the dispatcher hook with extra
> > > indentation? Maybe extra braces could further clarify, e.g.:
> > > 
> > > | hook postrouting {
> > > |         +0000000100 nf_nat_ipv6_out [nf_nat] {
> > > |                 +0000200000 chain inet nat postrouting [nft_chain_nat]
> > > |         }
> > > |         +2147483647 nf_confirm [nf_conntrack]
> > > | }
> > 
> > Actually  one could override the hook value with the one of the
> > nat base hook.  The ordering inside the dispatcher is whats important,
> > the exact numerical value isn't important.
> 
> Hmm. I like how one can use 'list hooks' output to find a good spot for
> a new base chain. The real nat chain priority value is needed for that,
> but no point in considering made up use-cases. Seeing the chains
> attached to a given nat dispatcher is already a step forward, and having
> their ordering is probably well enough.

I guess the goal is to expose iptables and nftables in place?

Is it really needed to expose this internal +0000200000?

Maybe simply report instead?

         +0000000100 nf_nat_ipv6_out [nf_nat]: chain ip nat POSTROUTING [iptable_nat]
         +0000000100 nf_nat_ipv6_out [nf_nat]: chain inet nat postrouting [nft_chain_nat]

Yes, it looks like a duplicate, but it is sort of how it works now, no
need to expose dispatcher details.