From: Martin Willi <martin@strongswan.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH netfilter/iptables] Add new slavedev match extension
Date: Fri, 10 Jan 2020 17:34:12 +0100 [thread overview]
Message-ID: <83ada82dbc93439d794c2407e3c91dd1b69bcbaa.camel@strongswan.org> (raw)
In-Reply-To: <20191217135616.25751-1-martin@strongswan.org>
Pablo,
> This patchset introduces a new Netfilter match extension to match
> input interfaces that are associated to a layer 3 master device. The
> first patch adds the new match to the kernel, the other provides an
> extension to userspace iptables to make use of the new match.
These patches have been marked as superseded in patchworks, likely due
to Florian's nftables version that has been merged.
While I very much appreciate the addition of VRF interface matching to
nftables, some users still depend on plain iptables for filtering. So I
guess there is some value in these patches for those users to extend
their filtering with VRF support.
Is there a chance of bringing in slavedev matching for iptables, or do
we have a policy to implement new features in nftables, only?
Thanks,
Martin
next prev parent reply other threads:[~2020-01-10 16:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 13:56 [PATCH netfilter/iptables] Add new slavedev match extension Martin Willi
2019-12-17 13:56 ` [PATCH nf-next] netfilter: xt_slavedev: Add new L3master slave input device match Martin Willi
2019-12-17 13:56 ` [PATCH iptables] extensions: Add new xt_slavedev input interface match extension Martin Willi
2020-01-10 16:34 ` Martin Willi [this message]
2020-01-16 19:59 ` [PATCH netfilter/iptables] Add new slavedev " Pablo Neira Ayuso
2020-01-17 12:00 ` Martin Willi
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=83ada82dbc93439d794c2407e3c91dd1b69bcbaa.camel@strongswan.org \
--to=martin@strongswan.org \
--cc=dsahern@gmail.com \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).