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