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.
