From: Phil Sutter <phil@nwl.cc>
To: Jan Engelhardt <jengelh@inai.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [iptables PATCH 04/23] libxtables: xtoptions: Treat NFPROTO_BRIDGE as IPv4
Date: Wed, 20 Dec 2023 22:35:01 +0100 [thread overview]
Message-ID: <ZYNeBT0gZr8th36e@orbyte.nwl.cc> (raw)
In-Reply-To: <479p662p-q879-869p-n2r4-o16175789q45@vanv.qr>
On Wed, Dec 20, 2023 at 08:20:10PM +0100, Jan Engelhardt wrote:
>
> On Wednesday 2023-12-20 17:06, Phil Sutter wrote:
>
> >When parsing for XTTYPE_HOST(MASK), the return value of afinfo_family()
> >is used to indicate the expected address family.
> >
> >Make guided option parser expect IPv4 by default for ebtables as this is
> >the more common case.
>
> ebtables is about Ethernet addresses mostly,
> and ebt_ip6 and ebt_ip have the same priority really.
That's right, but there's also libebt_arp which expects IPv4 address
in --arp-ip-src and --arp-ip-dst options.
I was a bit undecided about this solution because libebt_ip6's
workaround is fugly:
| xtables_set_nfproto(NFPROTO_IPV6);
| xtables_option_parse(cb);
| xtables_set_nfproto(NFPROTO_BRIDGE);
OTOH introducing XTTYPE_HOST{,MASK}{4,6} to force the expected address
family despite afinfo->family value seemed over-engineering given the
single user I had to cover after treating NFPROTO_BRIDGE as IPv4 by
default.
Cheers, Phil
next prev parent reply other threads:[~2023-12-20 21:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 16:06 [iptables PATCH 00/23] Guided option parser for ebtables Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 01/23] libxtables: xtoptions: Prevent XTOPT_PUT with XTTYPE_HOSTMASK Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 02/23] libxtables: xtoptions: Support XTOPT_NBO with XTTYPE_UINT* Phil Sutter
2023-12-20 19:07 ` Jan Engelhardt
2023-12-20 21:28 ` Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 03/23] libxtables: xtoptions: Implement XTTYPE_ETHERMACMASK Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 04/23] libxtables: xtoptions: Treat NFPROTO_BRIDGE as IPv4 Phil Sutter
2023-12-20 19:20 ` Jan Engelhardt
2023-12-20 21:35 ` Phil Sutter [this message]
2023-12-20 16:06 ` [iptables PATCH 05/23] ebtables: Support for guided option parser Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 06/23] extensions: libebt_*: Drop some needless init callbacks Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 07/23] extensions: libebt_stp: Use guided option parser Phil Sutter
2023-12-20 19:29 ` Jan Engelhardt
2023-12-20 21:47 ` Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 08/23] extensions: libebt_arpreply: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 09/23] extensions: libebt_dnat: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 10/23] extensions: libebt_ip6: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 11/23] extensions: libebt_ip: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 12/23] extensions: libebt_log: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 13/23] extensions: libebt_mark: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 14/23] extensions: libebt_nflog: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 15/23] extensions: libebt_snat: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 16/23] extensions: libebt_redirect: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 17/23] extensions: libebt_802_3: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 18/23] extensions: libebt_vlan: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 19/23] extensions: libebt_arp: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 20/23] extensions: libxt_limit: Use guided option parser for NFPROTO_BRIDGE, too Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 21/23] extensions: libebt_pkttype: Use guided option parser Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 22/23] extensions: libebt_mark_m: " Phil Sutter
2023-12-20 16:06 ` [iptables PATCH 23/23] extensions: libxt_HMARK: Review HMARK_parse() Phil Sutter
2024-01-10 15:09 ` [iptables PATCH 00/23] Guided option parser for ebtables Phil Sutter
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=ZYNeBT0gZr8th36e@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=jengelh@inai.de \
--cc=netfilter-devel@vger.kernel.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