-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 135d929..45dcf10 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
Hello everyone,
While testing the (very awesome!) bridge igmp/mld snooping support I came across
two issues which are breaking IPv6 multicast snooping and IPv6
non-link-local multicast on bridges with multicast snooping support enabled
in general. The first two patches shall fix these issues.
for transient multicast addresses instead of non-link-local
addresses.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index e8fdaab
These look correct. Did you test them with real traffic?
Yes, I did. With these patches the hashlist and linked lists per port
are being filled correctly for IPv6 - initially. Verified that with
both some printk()s for the per port mglists as well as with vlc. With
patch 5/5 this also worked
and only after that fetching the source address.
Reported-by: Jan Beulich jbeul...@novell.com
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge
One unrelated other observation with this change of yours:
daddr is an input argument to ipv6_dev_get_saddr(), yet
it gets initialized only after the function was called. Is that
really correct?
Hmm, that wasn't intentional. I tested that again and so far I still always
got the right source
Hi everyone,
Somehow I'm having trouble with the IPv6 bridge snooping again:
MLDv2 Reports are dropped by the multicast snooping feature, looks
like it has something to do with checksums. Wireshark does not
display any weirdness, it at least reports the MLD reports
checksum as correct.
The
Hi everyone,
The following two patches are fixing two issues, related to the parsing of
IPv6 MLD messages.
The first one fixes an observed issue which lead to ignored MLD messages.
In the tests this patch fixes the issue in my scenario. However I'm not
so familiar with the checksumming functions
when
parsing a snooped IPv6 MLDv1/2 message of another host, leading to
possibly ignored, though valid MLDv1/2 messages. This commit shall fix
this issue.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |5 -
1 files changed, 4 insertions(+), 1 deletions
substracting the offset and therefore to a very
high new value of 'len' due to its unsignedness. This will ultimately
lead to the pskb_trim_rcsum() practically never being called, even in
the cases where it should.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c
)
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 81f2389..d6448e3 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge
(bridge: Only flood unregistered groups
to routers) did for IPv4, let's do the same for IPv6 with the same
reasoning.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/bridge
Hi Herbert,
Were there any reasons I might not be aware of which prevented you
from adding the same change you introduced in
bridge: Only flood unregistered groups to routers for IPv6, too?
If not and if no one else comes up with any objection, then I'd
still be happy if this patch could find
of the querier is added to
give multicast responses enough time to arrive and to be learned from
before disabling the flooding behaviour again.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_device.c|3 ++-
net/bridge/br_input.c |3 ++-
net/bridge/br_multicast.c | 41
On Fri, Jul 26, 2013 at 11:19:00PM +0100, Adam Baker wrote:
On 25/07/13 14:56, Linus Lüssing wrote:
If there is no querier on a link then we won't get periodic reports and
therefore won't be able to learn about multicast listeners behind ports,
potentially leading to lost multicast packets
of the querier is added to
give multicast responses enough time to arrive and to be learned from
before disabling the flooding behaviour again.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
v3: changed type of multicast_querier_delay_time from
atomic64_t to unsigned long
v2: added missing, empty
by using separate timers for the snooped IGMP and MLD queries
as well as separate timers for our internal IGMP and MLD queriers.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_device.c|2 +-
net/bridge/br_input.c |2 +-
net/bridge/br_mdb.c | 14 ++-
net
Hi,
Here are two, small feature changes I would like to submit to increase
the usefulness of the multicast snooping of the bridge code.
The first patch is an unaltered one I had submitted before, but since it
got no feedback I'm resubmitting it here for net-next. With the recently
added patch to
The multicast snooping code should have matured enough to be safely
applicable to IPv6 link-local multicast addresses (excluding the
link-local all nodes address, ff02::1), too.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_mdb.c |3 ++-
net/bridge/br_multicast.c
(bridge: Only flood unregistered groups
to routers) did for IPv4, let's do the same for IPv6 with the same
reasoning.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/bridge
Hi Jan,
On Mon, Mar 03, 2014 at 02:47:15PM -0500, Jan Stancek wrote:
I'm seeing an issue where bridge (sometimes) stops forwarding ICMP6
neighbor solicitation packets to KVM guest and as result KVM guest doesn't
respond with neighbor advertisement.
Hm, okay, that's not supposed to happen.
On Mon, Mar 03, 2014 at 04:40:40PM -0500, Vlad Yasevich wrote:
I did notice a minor issue in the bridge code. The following
code:
/* Prevent flooding this packet if there is no listener present */
if (!ipv6_addr_is_ll_all_nodes(ip6h-daddr))
Hi Jan,
On Mon, Mar 03, 2014 at 05:45:49PM -0500, Jan Stancek wrote:
There is also bridge on host B. I assume that doesn't matter
but I could set up host B without bridge if needed.
It can matter, but in this case it doesn't :).
What I'm curious about is, whether the guest receives
the
On Tue, Mar 04, 2014 at 10:06:14AM +0100, Hannes Frederic Sowa wrote:
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index ef66365..fb0e36f 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1235,6 +1235,12 @@ static int
Hi Jan,
On Tue, Mar 04, 2014 at 03:02:36AM -0500, Jan Stancek wrote:
For the broken query, ok, it's your manually crafted query. But
did you see a query with such a bogus source address in the
wild, too? (I'm curious how urgent this sanity check is)
It's real packet I managed to capture
On Tue, Mar 04, 2014 at 06:06:29AM -0500, Jan Stancek wrote:
- Original Message -
From: Linus Lüssing linus.luess...@web.de
To: Jan Stancek jstan...@redhat.com
Cc: net...@vger.kernel.org, Florian Westphal fwest...@redhat.com,
bridge@lists.linux-foundation.org
Sent: Tuesday
traffic as the bridge did not learn
about these listeners.
With this patch the snooping code is enabled upon receiving valid,
general queries only.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
v2: unchanged
net/bridge/br_multicast.c |8 +---
1 file changed, 5 insertions(+), 3
On Mon, Mar 10, 2014 at 11:56:00PM +0100, Hannes Frederic Sowa wrote:
On Mon, Mar 10, 2014 at 10:25:25PM +0100, Linus Lüssing wrote:
br_multicast_query_received(br, port, br-ip6_querier,
- !ipv6_addr_any(ip6h-saddr), max_delay
-by: Hannes Frederic Sowa han...@stressinduktion.org
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 7b757b5..d2c3aae 100644
--- a/net
On Wed, Apr 23, 2014 at 02:47:48PM -0400, David Miller wrote:
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1282,8 +1282,7 @@ static int br_ip6_multicast_query(struct net_bridge
*br,
goto out;
}
- br_multicast_query_received(br, port,
Hi,
The first patch is simply a cosmetic patch. So far I (and maybe others
too?) have been regularly confusing these two structs, therefore I'd
suggest renaming them and therefore making the follow-up patches easier
to understand and nicer to fit in.
The second patch fixes a minor issue, but
the
struct bridge_mcast_querier but for storing information about the
selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_mdb.c |4 +-
net/bridge/br_multicast.c | 169
net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in IGMP/MLD queriers
to be able to reliably serve any multicast listener behind this same
bridge.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
Changes in v2:
* fix a nasty typo in PATCH 1/4, br_multicast_update_query_timer():
br-multicast_query_interval vs. br-multicast_querier_interval
= this accidentally reduced the other querier present timer
from 255 to 125 seconds
* fix a typo in PATCH 2/4, br_ip{4,6}_multicast_query():
the
struct bridge_mcast_querier but for storing information about the
selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_mdb.c |4 +-
net/bridge/br_multicast.c | 169
net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in IGMP/MLD queriers
to be able to reliably serve any multicast listener behind this same
bridge.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
the currently selected one. This slight optimization is
supposed to make it more RFC compliant (but is rather uncritical and
therefore probably not necessary to be queued for stable kernels).
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c | 101
net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
On Thu, Jun 05, 2014 at 12:43:11AM -0700, David Miller wrote:
From: Linus Lüssing linus.luess...@web.de
Date: Mon, 2 Jun 2014 20:42:15 +0200
Changes in v3:
* use EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL()
This is not a sufficient header posting.
You must also describe
The first patch is simply a cosmetic patch. So far I (and maybe others
too?) have been regularly confusing these two structs, therefore I'd
suggest renaming them and therefore making the follow-up patches easier
to understand and nicer to fit in.
The second patch fixes a minor issue, but probably
net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
the
struct bridge_mcast_querier but for storing information about the
selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_mdb.c |4 +-
net/bridge/br_multicast.c | 169
the currently selected one. This slight optimization is
supposed to make it more RFC compliant (but is rather uncritical and
therefore probably not necessary to be queued for stable kernels).
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c | 101
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in IGMP/MLD queriers
to be able to reliably serve any multicast listener behind this same
bridge.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux
Once my last patchset got applied, I got slapped by an automatic smatch
and build bot. Here are two patches fixing the according issues, a potential
null pointer dereference and a compile error when compiling without IPv6.
[PATCH 1/2] is probably not the ideal solution - the assignment of the
-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index cd3cf39..876e5fb 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1373,6 +1373,8 @@ static
)
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 876e5fb..abfa0b65 100644
--- a/net/bridge
Hi Ajith,
On Mon, Jun 23, 2014 at 07:58:21AM +0530, Ajith Adapa wrote:
Hi Luessing,
As per RFC 4541, snooping switches send query with source address as
0.0.0.0 since port in a L2 switch doesn't have ip-address configured.
Hm, I'm not quite sure whether this is true. Do you have a
Hi,
Some people pointed out to me that it might be helpful to add stubs for
the newly added multicast exports. That way e.g. batman-adv should continue
to be compile and useable without having to have a kernel compiled
with bridge code in the future. This is what the first patch is supposed
to
To make users (e.g. batman-adv soon) load- and runnable even if the
bridge was compiled without snooping capabilities - or even if the
kernel was compiled without any bridge code at all.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux/if_bridge.h | 14 ++
1
in the
future.
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
include/linux/if_bridge.h |6 ++
net/bridge/br_multicast.c | 37 +
2 files changed, 43 insertions(+)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index e0c575c
on general queries only
- 20a599bec (present since 3.14)
Let me know what you'd think about that or if there's any trouble
applying them to older kernels.
Cheers, Linus
On Tue, Mar 25, 2014 at 02:06:07PM +0100, Linus Lüssing wrote:
That commit is supposed to be a fix and seems to be a easily
::0001, \
IPv6 priority=0x0, Next Header=0
Signed-off-by: Linus Lüssing linus.luess...@web.de
---
net/bridge/br_multicast.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 7751c92..9d02e6c 100644
generated queries
- f0b4eeced (since 3.18)
If there's anything unclear, just let me know. Thanks :)!
Cheers, Linus
On Wed, Sep 10, 2014 at 03:33:41PM +0200, Linus Lüssing wrote:
I just got a complaint about bridges, multicast and a
3.10 kernel again. Seems like nobody had any objections about
On Tue, Feb 10, 2015 at 04:59:09PM +0300, Vasily Averin wrote:
I'm trying to fix ICMPv6 processing broken in OpenVZ after rebase to last
RHEL6u6 kernel.
After some unclear manipulation bridge begins to forward icmp6 NS (fe02::1)
into wrong port,
and at present I do not found the reason of
Hi Vasily,
On Tue, Feb 10, 2015 at 11:44:29AM +0300, Vasily Averin wrote:
This patch prevent forwarding of ICMPv6 in bridges,
so containers/VMs with virtual eth adapters connected in local bridge cannot
ping each other via ipv6 (but can do it via ipv4)
If a host wants to receive packets,
With this patch, the IGMP and MLD message validation functions are moved
from the bridge code to the IPv4/IPv6 multicast files. Some small
refactoring was done to enhance readibility and to iron out some
differences in behaviour between the IGMP and MLD parsing code (e.g. the
skb-cloning of MLD
Let's use these new, neat helpers.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
net/bridge/br_multicast.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index c465876..3c630c7
The multicast optimizations bridge integration will require the just
implemented IGMP/MLD report handling later. Therefore bumping the
version number.
---
net/batman-adv/multicast.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/multicast.c
With this patch IGMP or MLD reports are only forwarded to the selected
IGMP/MLD querier as RFC4541 suggests. This is necessary to avoid
multicast packet loss in bridged scenarios later:
An IGMPv2/MLDv1 querier does not actively join the multicast group the
reports are sent to. Because of this,
The last round of multicast patches send to the batman-adv mailinglist
to add support for the multicast optimizations in bridged scenarios, too,
unfortunately had one major conceptual flaw: It could lead to packet loss.
It's not sufficient to have the unicasting of reports implemented on
messages is now only done if necessary, just like the
IGMP part always did).
Finally, these IGMP and MLD message validation functions are exported so
that not only the bridge can use it but batman-adv later, too.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
include/linux/igmp.h |1
Let's use these new, neat helpers.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
net/bridge/br_multicast.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 4b6722f..b52f4cb
The multicast optimizations in batman-adv are yet only usable and
enabled in non-bridged scenarios. To be able to support bridged setups
batman-adv needs to be able to detect IGMP/MLD queriers and reports on
mesh nodes without bridges, too. See the following link for details:
On Fri, Apr 10, 2015 at 07:46:39PM +0200, Linus Lüssing wrote:
diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c
new file mode 100644
index 000..95b34c0
--- /dev/null
+++ b/net/ipv6/mcast_snoop.c
@@ -0,0 +1,198 @@
+/* Copyright (C) 2015: Linus Lüssing linus.luess...@c0d3.blue
The last round of multicast patches send to the batman-adv mailinglist
to add support for the multicast optimizations in bridged scenarios, too,
unfortunately had one major conceptual flaw: It could lead to packet loss.
It's not sufficient to have the unicasting of reports implemented on
Let's use these new, neat helpers.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
net/bridge/br_multicast.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index c465876..3c630c7
With this patch IGMP or MLD reports are only forwarded to the selected
IGMP/MLD querier as RFC4541 suggests. This is necessary to avoid
multicast packet loss in bridged scenarios later:
An IGMPv2/MLDv1 querier does not actively join the multicast group the
reports are sent to. Because of this,
The multicast optimizations bridge integration will require the just
implemented IGMP/MLD report handling later. Therefore bumping the
version number.
---
net/batman-adv/multicast.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/multicast.c
With this patch, the IGMP and MLD message validation functions are moved
from the bridge code to the IPv4/IPv6 multicast files. Some small
refactoring was done to enhance readibility and to iron out some
differences in behaviour between the IGMP and MLD parsing code (e.g. the
skb-cloning of MLD
even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
I'm currently a little unsure about a few things (that's why I'm sending
this as an RFC):
* For i=br_multicast_init(), e
On Thu, May 28, 2015 at 04:42:54AM -0700, Eric Dumazet wrote:
Intent of the code was to clear port field, not the pointer to querier.
Acked-by: Linus Lüssing linus.luess...@c0d3.blue
.
But since br_multicast_init() doesn't start any timers and only sets
default values and initializes timers it should be save to reconfigure
the default values after that, before things actually get active after
the bridge is set up.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
Changelog v3
even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
Changelog:
* [RFC PATCH net-next] - [PATCH net-next]
net/bridge/br_multicast.c | 15 ++-
1 file changed, 2 insertions
.
But since br_multicast_init() doesn't start any timers and only sets
default values and initializes timers it should be save to reconfigure
the default values after that, before things actually get active after
the bridge is set up.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
Changelog v2
of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.
Fixes: 9afd85c9e455 (net: Export IGMP/MLD message validation code)
Reported-by: Brenden Blanco bbla...@plumgrid.com
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
net
Hi Saurav,
On Fri, Jul 31, 2015 at 03:50:35PM +0530, saurav barik wrote:
I am working on an Access Point device (AP1) running linux kernel 3.0.34 on
which my bridge configuration is as follows.
There were quite some crucial bugs, I'm not quite sure whether
3.0.34 was actually usuable for
Hi bridge folks,
I'm currently stuck with a simple scenario where enabling bridge
multicast snooping causes packetloss for some time:
--
(c) <~~~> (A) <---> (B)
(c) is a wifi client, connected to a wifi access point (A).
(B) is another AP connected to (A) via ethernet cable.
The
Hi tpowa,
Thanks for your feedback.
On Mon, Sep 07, 2015 at 02:46:27PM +0200, Tobias Powalowski wrote:
> Hi,
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9afd85c9e4552b276e2f4cfefd622bdeeffbbf26
>
> This commit introduces a weird behaviour on my dlna server.
Hi Tobias,
On Tue, Sep 08, 2015 at 08:36:02AM +0200, Tobias Powalowski wrote:
> Am 08.09.2015 um 04:24 schrieb Linus Lüssing:
> > Hi tpowa,
> >
> > Thanks for your feedback.
> >
> >
> > On Mon, Sep 07, 2015 at 02:46:27PM +0200, Tobias Powalowski wrote:
&g
On Tue, Sep 08, 2015 at 08:52:56AM -0700, Stephen Hemminger wrote:
> Why doesn't the client resend a IGMP when it notes
> a connection change?
>
Good question, I actually had expected that too. My guess is that the
network stack might be interpreting the RFCs in a "conservative
way". RFC3376
Powalowski <tobias.powalow...@googlemail.com>
Tested-by: Tobias Powalowski <tobias.powalow...@googlemail.com>
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
net/bridge/br_multicast.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c
Hi Daniel,
Thanks for submitting this patch here :).
On Thu, Jun 23, 2016 at 11:28:55AM +0200, daniel wrote:
> The bridge is falsly dropping ipv6 mulitcast packets
> if there is no ipv6 address assigned on the brigde and no
> external mld querier is present.
and if the bridge internal querier
ddress assinged to the bridge
> and returns a false state for the local querier in
> __br_multicast_querier_exists().
Acked-by: Linus Lüssing <linus.luess...@c0d3.blue>
On Mon, Jun 27, 2016 at 08:10:48PM +0200, Nikolay Aleksandrov via Bridge wrote:
> These are invaluable when monitoring or debugging complex multicast setups
> with bridges.
Indeed! Great patch :). Especially if people are unable to provide
pcap files for debugging (due to whatever reason).
On Fri, Jun 24, 2016 at 12:35:18PM +0200, Daniel Danzberger wrote:
> The bridge is falsly dropping ipv6 mulitcast packets if there is:
> 1. No ipv6 address assigned on the brigde.
> 2. No external mld querier present.
> 3. The internal querier enabled.
>
> When the bridge fails to build mld
lticast_rcv+0x5dc/0xd00)
[ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>]
(br_handle_frame_finish+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com>
Signed-off-by: Linus
lticast_rcv+0x5dc/0xd00)
[ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>]
(br_handle_frame_finish+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com>
Signed-off-by: Lin
sh+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com>
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
Steinar, can you check whether this fixes the bridge issues you reporte
On Sat, Feb 13, 2016 at 03:35:28AM +0100, Linus Lüssing wrote:
> PS: 4.4.0 did not have c2d4fb yet, that was added with 4.4.1. While
> missing it does cause trouble, it should not cause a csum error.
Just for the record: I was wrong here, that patch was part of v4.4
already and even v4.3.
Hi Alvaro,
Did you have a chance to narrow it down to that commit yet? Would
be great if you could check whether reverting the following
commits helps:
c2d4fbd2163e ("bridge: fix igmpv3 / mldv2 report parsing")
a516993f0ac1 ("net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code")
Ok, was able to borrow a Raspi 2 and indeed I can reproduce the
issue there.
Reverting these patches helps:
On Sat, Feb 13, 2016 at 03:35:28AM +0100, Linus Lüssing wrote:
> c2d4fbd2163e ("bridge: fix igmpv3 / mldv2 report parsing")
> a516993f0ac1 ("net: fix wrong skb_get()
this by taking the offset between IP and IGMP/MLD header into
account, too.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
net/bridge
this by taking the offset between IP and IGMP/MLD header into
account, too.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
v2: changed "i
On Tue, May 03, 2016 at 01:26:23PM -0700, Stephen Hemminger wrote:
> On Tue, 3 May 2016 22:18:54 +0200
> Linus Lüssing <linus.luess...@c0d3.blue> wrote:
>
> > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> > index 03661d9..7105cdf 100644
> >
On Tue, Jun 28, 2016 at 08:04:42AM -0400, David Miller wrote:
> From: Linus Lüssing <linus.luess...@c0d3.blue>
> [...]
> > Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()")
>
> You're missing an initial 'd' in that SHA1-ID.
>
>
tch fixes this by always resending MLD reports when an interface
change happens, for instance from NO-CARRIER to CARRIER state.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
Initial problem report was sent to the bridge mailing list a while ago:
- https://lists.linuxfounda
kau <n...@nbd.name>
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust
1 - 100 of 203 matches
Mail list logo
