netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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