Hi, On Mon, Jul 29, 2024 at 05:32:11PM +0200, Florian Westphal wrote: [...] > inet ingress is already awkward in my opinion, I'm not sure why it > got added. I suppose the ability to reuse other inet family ruleset parts for ingress was a sought-after feature. In hindsight, making tables family-agnostic and thus pure "containers" for grouping ruleset parts might be a superior design choice. (Or maybe I just miss the rub in doing that. :) [...] > I agree that we first need to figure out what 'nft list hooks xxxx' > should do. I would prefer 'no guesses' approach, i.e. Let me suggest a deviation which seems more user-friendly: > 1. nft list hooks > dump everything EXCEPT netdev families/devices Include netdev here, make it really list *all* hooks. Iterating over the list of currently existing NICs in this netns is no big deal, is it? > 2. nft list hooks netdev device foo > dump ingress/egress netdev hooks, > INCLUDING inet ingress (its scoped to the device). Drop 'netdev' from the syntax here. The output really is "all hooks specific to that NIC", not necessarily only netdev ones. (And "device" is a distinct identifier for network interfaces in nftables syntax.) > 3. nft list hooks arp > dump arp input and output, if any > 4. nft list hooks bridge > dump bridge pre/input/forward/out/postrouting > 5. nft list hooks ip > dump ip pre/input/forward/out/postrouting > 6. nft list hooks ip6 -> see above > 7. nft list hooks inet -> alias for dumping both ip+ip6 hooks. I wonder if this is more confusing than not - on the netfilter hooks layer, it doesn't quite exist. The only thing which persists a tad longer is inet ingress, indicated by nf_register_net_hook() passing it down to __nf_register_net_hook for nf_hook_entry_head() to return the same value as for netdev ingress. I guess they could be spliced even further up. > This also means that i'd make 'inet device foo' return a warning > that the device will be ignored because "inet ingress" is syntactic > frontend sugar similar to inet pseudo-family. Iff my claim holds true, there is no such thing as an inet hook and thus also no inet device one. :) > We could try the 'detect pipeline' later. But, as per example > above, I don't think its easy, unless one omits all packet rewrites > (stateless nat, dnat, redirect) and everything else that causes > re-routing, e.g. policy routing, tproxy, tc(x), etc. > > And then there is l3 and l2 multicasting... > > But, admittingly, it might be nice to have something and it might be > good enough if pipeline alterations by ruleset and other entities > are omitted. I seem to recall us discussing something like that on NFWS, but to simulate traversal of a packet with given properties through the ruleset. Which would also identify the hooks involved, I guess? Cheers, Phil
