On Mon, Jul 29, 2024 at 01:37:36AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > Not really, why would eth0 and eth1 be related here?
> >
> > Note that you can specify:
> >
> > list hooks ip device enp0s25
> >
> > this shows the hooks that will be exercised for a given packet family,
> > ie. IPv4 packets will exercise the following hooks.
> >
> > family ip {
> > hook ingress {
> > 0000000000 chain netdev x y [nf_tables]
> > }
> > hook prerouting {
> > -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
> > -0000000200 ipv4_conntrack_in [nf_conntrack]
> > }
> > hook input {
> > 0000000000 chain ip filter in [nf_tables]
> > +2147483647 nf_confirm [nf_conntrack]
> > }
> > hook forward {
> > -0000000225 selinux_ip_forward
> > }
> > hook output {
> > -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
> > -0000000225 selinux_ip_output
> > -0000000200 ipv4_conntrack_local [nf_conntrack]
> > }
> > hook postrouting {
> > +0000000225 selinux_ip_postroute
> > +2147483647 nf_confirm [nf_conntrack]
> > }
> > }
> >
> > This is _not_ showing the list of hooks for a given family.
>
> I now realize that whats in the tree today is not what I wrote originally.
We agreed to change it.
> So this is neither showing the hooks that will be execrised (packet
> can't be input and forward...). But ok. I don't know what to do now.
As it is not possible to know where the packet is going (input /
forward), this listing represents what hooks can be potentially
exercised for such packet family, hence, netdev hooks are included in
the ip family view.
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.
> > What I meant is that user could filter out by ingress and egress
> > device to fetch the hooks that are traversed in such case, ie.
> >
> > list hooks ip iifname eth0 oifname eth1
> >
> > to get the traversal of hooks for IPv4 packets, assuming eth0 as
> > ingress device and eth1 as egress device.
>
> No idea how to make this, or I fail to understand.
Not important for this series, this can be extended later.
> > > What would make more sense to me is to allow
> > >
> > > list hooks netdev
> > >
> > > and then have nft fetch list of all network devices and then query them
> > > all.
> >
> > Makes sense, it currently fails with EINVAL because no device has been
> > specified.
>
> I'll try to add it, but I don't know if I should toss these patches
> first or not :/
I think patchset looks fine, but documentation update needs a revamp
if you agree in the existing behaviour.
