Re: [PATCH nft 1/4] doc: add documentation about list hooks feature

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

On Mon, Jul 29, 2024 at 05:32:11PM +0200, Florian Westphal wrote:
[...]
> TL;DR: I think we should revert to strict behaviour, i.e.
> nft list hooks foo

Agreed.

> queries hooks registered as NFPROTO_FOO.
> 
> NFPROTO_INET expands to shorthand for 'list hooks ip and ip6'.
> 
> AFAICS the problem is that ip, ip6 and arp are both NFPROTO_ values
> (protocol families), but also l3 protocols, whereas netdev and bridge
> are only families.
> 
> Hence, what to do on bridge becomes murky, there is just a large number
> of possible l3 protocols that can pass through these hooks.
> 
> Netdev is simple because its scoped only to one single interface.
> 
> Sorry for the wall of text below, but maybe it helps to understand
> why i think the above (no-guesses, treat strictly as nfproto) makes sense.

Makes sense, thanks for explaining.

[...]
> > If you don't like this behaviour and prefer a strict view per hook
> > family it should be possible to revisit. User will have to get all the
> > pieces together to understand what the hook pipeline is instead. This
> > command has not been documented so far.
> 
> Yes.  In theory it should be possible to do this, so to go with arp example:
> 
>   nft list hooks arp device foo
> 
> would list:
> 
> 1. netdev ingress and egress hook for the queried device
> 2. arp in and output hooks (there is no forward for arp)
> 3. bridge pre,in,forward,output and postrouting
> 
> but does that make sense?  I don't think so, because it gets more
> complicated for bridge query:
> 
> nft list hooks bridge
> 
> 1. can't show netdev, we lack device to query -> query all interfaces?
>    But why would one clutter output with netdev in/egress when bridge
>    was asked for?
> 2. show pre/in/fwd/out/postrouting NFPROTO_BRIDGE hooks
> 3. should it show ip/ip6 hooks? They could be relevant in case
>    of broute expression in nftables.
>    ip/ip6 Output+postrouting are travesed in case of local packets.
> 
> and it would have to show arp hooks, no?  for arp packet, we might pass
> them up to local stack.  Local arp query pass through arp:output.
> 
> So I'm just worried that this gets complicated/murky as to what is shown
> (and what is omitted).  For bridge, we would have to end up dumping
> everything and treat it like 'list hooks'....
> 
> I do admit that it would be nice to have something like:
> 
> nft list pipeline meta input eth0 ip saddr 1.2.3.4 ip daddr 5.6.7.8
> 
> and then have nft:
> 1. list NFPROTO_NETDEV for eth0 ingress only (no egress)
> 2. list NFPROTO_INET hooks for ingress eth0
> 3. list NFPROTO_IPV4 hooks for prerouting
> 4. query FIB to get output device for 1.2.3.4->5.6.7.8
> 5. list NFPROTO_IPV4 for EITHER input or forward+postrouting
> 6. for forward case, list NFPROTO_NETDEV egress hooks for the
> fib-derviced output device
> 
> But thats hard, because there might be rules in place that
> alter ip daddr or ip saddr, or packet mark etc etc so the
> pipeline shown can be a wrong.

Yes, providing a pipeline description is a much wider task than just
listing hooks. Please, move on with restoring list hooks.

Thanks Florian.