From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
netfilter-devel@vger.kernel.org, Phil Sutter <phil@nwl.cc>
Subject: Re: [PATCH nft 1/4] doc: add documentation about list hooks feature
Date: Fri, 26 Jul 2024 14:31:52 +0200 [thread overview]
Message-ID: <20240726123152.GA3778@breakpoint.cc> (raw)
In-Reply-To: <ZqNlvkJ2YSc-KIKb@calendula>
Pablo Neira Ayuso <pablo@netfilter.org> 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?
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.
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.
next prev parent reply other threads:[~2024-07-26 12:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 1:58 [PATCH nft 0/4] list hooks refactoring Florian Westphal
2024-07-26 1:58 ` [PATCH nft 1/4] doc: add documentation about list hooks feature Florian Westphal
2024-07-26 9:00 ` Pablo Neira Ayuso
2024-07-26 12:31 ` Florian Westphal [this message]
2024-07-28 23:19 ` Pablo Neira Ayuso
2024-07-28 23:37 ` Florian Westphal
2024-07-29 0:21 ` Pablo Neira Ayuso
2024-07-29 15:32 ` Florian Westphal
2024-07-30 23:34 ` Pablo Neira Ayuso
2024-08-13 11:06 ` Phil Sutter
2024-08-19 10:56 ` Pablo Neira Ayuso
2024-08-19 12:10 ` Florian Westphal
2024-07-26 1:58 ` [PATCH nft 2/4] src: remove decnet support Florian Westphal
2024-07-29 23:23 ` Florian Westphal
2024-07-26 1:58 ` [PATCH nft 3/4] src: mnl: clean up hook listing code Florian Westphal
2024-07-26 1:58 ` [PATCH nft 4/4] src: add egress support for 'list hooks' Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240726123152.GA3778@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.