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