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

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

Hi Phil, Florian,

@Florian, could you push out what you have to flush your queue in this front?

On Tue, Aug 13, 2024 at 01:06:49PM +0200, Phil Sutter wrote:
> On Mon, Jul 29, 2024 at 05:32:11PM +0200, Florian Westphal wrote:
> [...]
> 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?

I like this suggestion.

I think it should be possible to incrementally extend with these
suggestions, it should be possible to submit patches for your review.

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

I think allowing 'device foo' without family would be good.

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

inet is an "alias". I think dumpg both ip+ip6 hooks should be fine.

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

Yes, this all is more complicated and it needs a whole lot of work to
add this feature in a complete way, which makes sense to schedule this
for the _future_.