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

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> 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.
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.

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

> > 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 :/