All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Baker <linux@baker-net.org.uk>
To: herbert@gondor.apana.org.au
Cc: netdev@vger.kernel.org, Stephen Hemminger <shemminger@vyatta.com>,
	bridge@lists.linux-foundation.org
Subject: [Bridge] Problem with multicast traffic when using network bridging
Date: Sat, 23 Feb 2013 18:24:48 -0000	[thread overview]
Message-ID: <51290810.5060205@baker-net.org.uk> (raw)

After upgrading the kernel on the box that acts as a bridge between my 
wireless and wired networks I observed that access to my UPnP media 
servers became unreliable.

I tried a number of kernel versions to attempt to establish when things 
went wrong and got as far as

3.4 - works
3.5.7 - doesn't work
3.6.11 - doesn't work
3.7.1 - doesn't work
3.7.6 - doesn't work

I can test other versions if required but it doesn't always fail 
instantly and sometimes takes several hours before I notice it has 
failed so don't expect a quick response

All of the above are built with
CONFIG_BRIDGE_IGMP_SNOOPING=y

Knowing that I wasn't having problems with other traffic and the UPnP 
was the only protocol I use that relies on multicast I started looking 
at what changed in the file net/bridge/br_multicast.c and found the patch

bridge: Add multicast_querier toggle and disable queries by default
http://patchwork.ozlabs.org/patch/152295/

so tried

echo 1 >/sys/class/net/br0/bridge/multicast_querier

and after 48 hours of testing running kernel 3.7.6 it seems to be 
working reliably.

Whilst setting that value manually at boot time would be adequate to 
meet my needs it is reasonable to assume that vendors will build 
wireless access points using new kernels that would also exhibit this 
behaviour and users may not be able to get at the internals easily to 
change this configuration.

I therefore suspect that the assumption this patch makes that generating 
queries in the bridge is only an optimisation and isn't necessary isn't 
universally true.

Other details about my network configuration that may be relevant:
There are 2 UPnP media servers, one on the bridge machine and one on a 
machine on the wired network
There are 1 or 2 UPnP media control point / renderers, both on the 
wireless network
As I'm not using multicast on offsite links the IGMP proxy setting is 
disabled on my ADSL router (which is connected to the wired network)

Things I think are irrelevant but I'll mention just in case:
Bridge machine is a Marvell Kirkwood ARM5TE CPU
The wired network includes some homeplug connections

Have I done something unreasonable with my configuration or have I found 
a bug?

Thanks

Adam Baker

WARNING: multiple messages have this Message-ID (diff)
From: Adam Baker <linux@baker-net.org.uk>
To: herbert@gondor.apana.org.au
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	bridge@lists.linux-foundation.org, netdev@vger.kernel.org
Subject: Problem with multicast traffic when using network bridging
Date: Sat, 23 Feb 2013 18:18:56 +0000	[thread overview]
Message-ID: <51290810.5060205@baker-net.org.uk> (raw)

After upgrading the kernel on the box that acts as a bridge between my 
wireless and wired networks I observed that access to my UPnP media 
servers became unreliable.

I tried a number of kernel versions to attempt to establish when things 
went wrong and got as far as

3.4 - works
3.5.7 - doesn't work
3.6.11 - doesn't work
3.7.1 - doesn't work
3.7.6 - doesn't work

I can test other versions if required but it doesn't always fail 
instantly and sometimes takes several hours before I notice it has 
failed so don't expect a quick response

All of the above are built with
CONFIG_BRIDGE_IGMP_SNOOPING=y

Knowing that I wasn't having problems with other traffic and the UPnP 
was the only protocol I use that relies on multicast I started looking 
at what changed in the file net/bridge/br_multicast.c and found the patch

bridge: Add multicast_querier toggle and disable queries by default
http://patchwork.ozlabs.org/patch/152295/

so tried

echo 1 >/sys/class/net/br0/bridge/multicast_querier

and after 48 hours of testing running kernel 3.7.6 it seems to be 
working reliably.

Whilst setting that value manually at boot time would be adequate to 
meet my needs it is reasonable to assume that vendors will build 
wireless access points using new kernels that would also exhibit this 
behaviour and users may not be able to get at the internals easily to 
change this configuration.

I therefore suspect that the assumption this patch makes that generating 
queries in the bridge is only an optimisation and isn't necessary isn't 
universally true.

Other details about my network configuration that may be relevant:
There are 2 UPnP media servers, one on the bridge machine and one on a 
machine on the wired network
There are 1 or 2 UPnP media control point / renderers, both on the 
wireless network
As I'm not using multicast on offsite links the IGMP proxy setting is 
disabled on my ADSL router (which is connected to the wired network)

Things I think are irrelevant but I'll mention just in case:
Bridge machine is a Marvell Kirkwood ARM5TE CPU
The wired network includes some homeplug connections

Have I done something unreasonable with my configuration or have I found 
a bug?

Thanks

Adam Baker

             reply	other threads:[~2013-02-23 18:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-23 18:18 Adam Baker [this message]
2013-02-23 18:24 ` [Bridge] Problem with multicast traffic when using network bridging Adam Baker

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=51290810.5060205@baker-net.org.uk \
    --to=linux@baker-net.org.uk \
    --cc=bridge@lists.linux-foundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /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.