From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Bernhard Thaler <bernhard.thaler@wvnet.at>
Cc: kadlec@blackhole.kfki.hu, netfilter-devel@vger.kernel.org
Subject: Re: [PATCHv2 nf] netfilter: bridge: fix IPv6 packets not being bridged with CONFIG_IPV6=n
Date: Mon, 20 Jul 2015 15:18:49 +0200 [thread overview]
Message-ID: <20150720131849.GA20145@salvia> (raw)
In-Reply-To: <55A991B6.3080608@wvnet.at>
On Sat, Jul 18, 2015 at 01:37:26AM +0200, Bernhard Thaler wrote:
>
>
> On 16.07.2015 13:17, Pablo Neira Ayuso wrote:
> > On Thu, Jul 16, 2015 at 02:34:44AM +0200, Bernhard Thaler wrote:
> > [...]
> >> * checkpatch.pl throws error "ERROR: do not initialise statics to 0 or NULL"
> >> but left for consistency with similar declarations
> >
> > I'd appreciate if you can address this in first place, so we don't have
> > to undo what we've just done for the ip6tables LOCs.
> >
>
> OK, will do so.
>
> >> * dependency to CONFIG_IPV6 instead of CONFIG_IP6_NF_IPTABLES would be more
> >> "conservative" approach as br_netfilter_ipv6.o was introduced due to
> >> dependencies in br_validate_ipv6() to CONFIG_IPV6; but CONFIG_IP6_NF_IPTABLES
> >> will be needed for ip6tables so this dependency may be more "holistic"
> >
> > I'm fine if you want to restrict this to ip6tables. This may break
> > out-of-tree modules since they may be relying on these hooks, but we
> > don't care about those.
> >
>
> Wasn't aware of that. Don't really want to break functionality for
> anybody...but if you are fine with the change as it is I leave it as it is.
>
> > I think this s/CONFIG_IPV6/CONFIG_IP6_NF_IPTABLES should come in a
> > separated patch, just after the one that removes the checkpatch
> > errors I'd suggest.
> >
>
> OK will do so.
>
> >> * CONFIG_IP6_NF_IPTABLES=n makes br_validate_ipv6() being imported from
> >> br_netfilter.h; it is used in br_netfilter_hooks.c within br_nf_forward_ip()
> >> and br_nf_dev_queue_xmit() and returns -1 which will lead to NF_DROP;
> >> After defaulting /proc/sys/net/bridge/bridge-nf-call-ip6tables to 0 with
> >> CONFIG_IP6_NF_IPTABLES=n these two functions me never see IPV6 packets and
> >> therefore this may not be a problem; I was not able to fully confirm this
> >
> > It would be great if you can reduce #ifdef pollution. Now that we have
> > a br_netfilter_ipv6.c file, I think it should be possible to move the
> > IPv6 specific code there, at least the /proc code chunk.
> >
> > Could you have a look into this? Thanks!
> >
>
> I don't like the #ifdef pollution as well. But I do not find a good
> solution to avoid it for brnf_call_ip6tables definition.
> I had a look into putting the /proc entry code into br_netfilter_ipv6.c
> but I may need some pointers/help how to do it:
>
> - br_netfilter_init() calls register_net_sysctl() with brnf_table[] as
> argument to setup the sysctl entries
> - brnf_table[] is initialized with static number of elements in
> br_netfilter_hooks.c, with the current code I see no way how to set this
> single ip6tables array element in br_netfilter_ipv6.c
>
> Currently I see not other solution than using the #ifdef in the
> definition of ip6tables sysctl entry in brnf_table[].
I think you can add a new brnf_table_ipv6[] to the br_netfilter_ipv6.c
file, then pass it to register_net_sysctl using "net/bridge".
Then in br_netfilter_hooks.c, from the init path, you can call
something like:
br_nf_ipv6_proc_register();
>From the header file, you can define this like:
#ifdef IS_ENABLED(CONFIG_IPV6)
int br_nf_ipv6_proc_register(void);
#else
static inline int br_nf_ipv6_proc_register(void)
{
return 0;
}
#endif
So it becomes noop if IPv6 is not set.
prev parent reply other threads:[~2015-07-20 13:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-05 21:15 [RFC PATCH nf] netfilter: bridge: fix IPv6 packets not being bridged with CONFIG_IPV6=n Bernhard Thaler
2015-07-05 21:53 ` Florian Westphal
2015-07-06 21:00 ` Bernhard Thaler
2015-07-06 21:41 ` Florian Westphal
2015-07-15 17:47 ` Pablo Neira Ayuso
2015-07-16 0:34 ` [PATCHv2 " Bernhard Thaler
2015-07-16 11:17 ` Pablo Neira Ayuso
2015-07-17 23:37 ` Bernhard Thaler
2015-07-20 13:18 ` Pablo Neira Ayuso [this message]
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=20150720131849.GA20145@salvia \
--to=pablo@netfilter.org \
--cc=bernhard.thaler@wvnet.at \
--cc=kadlec@blackhole.kfki.hu \
--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;
as well as URLs for NNTP newsgroup(s).