Hi Florian,
On Fri, Jul 26, 2024 at 02:31:52PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > +*list hooks* is enough to display everything that is active
> > > +on the system, however, it does currently omit hooks that are
> > > +tied to a specific network device (netdev family). To obtain
> > > +those, the network device needs to be queried by name.
> >
> > IIRC, the idea is to display the ingress path pipeline according to
> > the device (if specified)
> >
> > list hooks netdev eth0
> >
> > as for egress, as it is not possible to know where the packet is
> > going, it is probably good to allow the user to specify the output
> > device, so it gets the entire pipeline for ingress and egress
> > paths, ie.
> >
> > list hooks netdev eth0 eth1
>
> 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.
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.
> 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.
> If a packet coming in on devX will be forwarded to devY depends on the
> type of packet and the configuration, e.g. arp/ip vs. bridge/routing
> or even encapsulation...
>
> > Note that this is not implemented. This has limitations, discovering
> > eth{0,1} belongs to bridge device would need more work (not asking to
> > do this now, but it could be a nice usability feature to discover the
> > pipeline?).
>
> Bridge? I don't think we have bridge family support for netdev hooks?
> AFAIU its only netdev and inet.
>
> This thing should only list the nf hooks registered for the device,
> and not start to guess. So for "list hooks br0", return ingress and
> egress hooks for the virtual device, not the bridge ports.
OK
