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

[Phil Sutter <phil@nwl.cc>]

On Thu, Mar 19, 2026 at 05:04:18PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > These chains are indirectly attached to the hook since they are
> > not called for packets belonging to an established connection.
> > 
> > Introduce NF_HOOK_OP_NAT to identify the container and dump attached
> > entries instead of the container itself.
> 
> Please lets not do this.
> 
> Before:
> 
>         hook postrouting {
>                 +0000000100 nf_nat_ipv6_out [nf_nat]
>                 +2147483647 nf_confirm [nf_conntrack]
>         }
> 
> After:
>         hook postrouting {
>                 +0000200000 chain inet nat postrouting [nft_chain_nat]
>                 +2147483647 nf_confirm [nf_conntrack]
>         }
> 
> ... and thats not true.  The nat chain isn't hooked at 200000.
> 
> It hooks at +100, this is a dispatcher.
> Concealing the actual hook location and then unrolling the embedded
> nat hooks gives a wrong impression and will mislead users wrt. the
> actual ordering.

Ah, so the nat-type chain's priority value orders it inside the
dispatcher's list.

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]
| }

> If we really want the ability to list the nat hooks, I think this
> needs a new command to dump them.

We may change 'nft list hooks' output arbitrarily, right? Or should we
fear braking some third-party parsers when doing too fancy stuff?

Thanks, Phil