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

[Phil Sutter <phil@nwl.cc>]

Hi Pablo,

On Fri, Mar 20, 2026 at 01:24:40AM +0100, Pablo Neira Ayuso wrote:
> 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?

No, I merely want to expose nat-type nftables chains. With iptables, I
see that we only get ipt_do_table instead of a chain name, but "fixing"
that is probably not worth the effort.

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

A remark from a practical perspective: Florian's suggestion to dump the
nat-type chains in their order with the dispatcher's priority value is
super-easy to implement (just have to pass the priority value to
nfnl_hook_dump_one() via parameter) and does not require adjustments in
user space.

Given the benefit for current and older user space, I'd go with that
first and decide if we add extra netlink attributes to nat-type chain
messages for user space to print more details.

Cheers, Phil