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
---
include/linux/igmp.h |1 +
include/linux
anged even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing
---
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=br_multic
On Thu, May 21, 2015 at 11:49:21AM +0800, Herbert Xu wrote:
> The timer operations are all supposed to be idempotent. So enabling
> a port twice or stopping it twice should be OK.
Oki doki.
>
> > * Might calls to br_multicast_add_router() via br_multicast_enable_port()
> > cause unintended si
anged even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing
---
Changelog:
* [RFC PATCH net-next] -> [PATCH net-next]
net/bridge/br_multicast.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(
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
---
Changelog v2:
* remove anothe
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
---
Changelog v3:
* Readded two b
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
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 mult
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
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |4 ++--
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.
Did
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 wifi-ap
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 ("In
Tested-by: Tobias Powalowski
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 66efdc2..480b3de 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_m
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")
9afd8
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()
sh+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas
Signed-off-by: Linus Lüssing
---
Steinar, can you check whether this fixes the bridge issues you reported on
bugzilla #99081? Not quite sure whether it is the sa
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.
On Thu, Feb 18, 2016 at 01:51:34PM +0100, Steinar H. Gunderson wrote:
> On Mon, Feb 15, 2016 at 03:07:06AM +0100, Linus Lüssing wrote:
> > Steinar, can you check whether this fixes the bridge issues you reported on
> > bugzilla #99081? Not quite sure whether it is the same as your
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
Signed-off-by: Linus Lüssing
-
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
Signed-off-by: Linus Lüssing
---
v3:
*
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
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c | 12 +++-
1 file changed, 7 insertions(+), 5
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 wrote:
>
> > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> > index 03661d9..7105cdf 100644
> > --- a/net/bridge/br_multi
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
Signed-off-by: Linus Lüssing
---
v2: changed "int" to "unsigned int"
net/bridge/br_multicast
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 i
ssinged to the bridge
> and returns a false state for the local querier in
> __br_multicast_querier_exists().
Acked-by: Linus Lüssing
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 que
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). Hopeful
On Tue, Jun 28, 2016 at 08:04:42AM -0400, David Miller wrote:
> From: Linus Lüssing
> [...]
> > Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()")
>
> You're missing an initial 'd' in that SHA1-ID.
>
> With that fixed, app
On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge wrote:
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index 1da3221845f1..ed0dd3340084 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -362,7 +362,7 @@ static struct net_bridge_port *new_nbp(struct
On Wed, Aug 31, 2016 at 08:02:22AM +0200, Nikolay Aleksandrov wrote:
> On 31/08/16 03:37, Linus Lüssing wrote:
> > On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge
> > wrote:
> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> >>
On Fri, Nov 04, 2016 at 08:44:48PM +, Corey Melanson wrote:
> After the live migration, multicast traffic to 239.236.15.150 stops as
> expected. If I try to manually add the multicast group membership:
> # bridge mdb add dev br.128 port vnet3 grp 239.236.15.150 temp
> # bridge mdb list |
On Wed, Nov 16, 2016 at 05:24:36PM +, Corey Melanson wrote:
> Please let me know if there is any other information that would be helpful.
>
> Thank you,
> Corey
Hi Corey,
I tried to reproduce your issue in a similar VM setup, but was
unsuccessful so far. For me things seem to work with 4.9-r
packets than broadcast ones
(e.g. wifi).
However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. This feature is disabled by default.
The initial patch and idea is from Felix Fietkau.
Cc: Felix Fietkau
Signed-off-by: Linus Lüssing
---
This feature
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> >
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature d
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcas
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the f
On Mon, Jan 09, 2017 at 09:05:49AM +0100, Johannes Berg wrote:
> On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
>
> > Actually, I do not quite understand that remark in the mac80211
> > multicast-to-unicast patch. IP should not care about the ethernet
> > heade
On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due to
> > the snooping knowledge, but the code is
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote:
> On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote:
> > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote:
> > >
> > > > > A host SHOULD silently discard a datagr
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
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 multicast
delivery and multicast at higher rates (e.g. multicast streaming
+ style fixes, commit message]
Signed-off-by: Linus Lüssing
---
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 multicast
delivery and multicast at higher rates (e.g. multicast streaming).
In OpenWRT/LEDE the
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
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 multicast
delivery and multicast at higher rates (e.g. multicast streaming
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
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 multicast
delivery and multicast at higher rates (e.g. multicast streaming
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
---
Initial problem report was sent to the bridge mailing list a while ago:
- https://lists.linuxfoundation.org/pipermail/bridge/2015-Se
PACKET_OTHERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing
---
net/bridge/br_input.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 013f2290b..ec83175 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_i
On Wed, Mar 15, 2017 at 11:42:11AM +0100, Pablo Neira Ayuso wrote:
> I'm missing then why redirect is not then just enough for Linus usecase.
For my usecase, the MAC address is configured by the user from a
Web-UI. It may or may not be the one from the bridge device.
Besides, found it counter int
On Wed, Mar 15, 2017 at 07:15:39PM +0100, Pablo Neira Ayuso wrote:
> Could you update ebtables dnat to check if the ethernet address
> matches the one of the input bridge interface, so we mangle the
> ->pkt_type accordingly from there, instead of doing this from the
> core?
Actually, that was the
On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote:
> Wait.
>
> May this break local multicast listener that are bound to the bridge
> interface? Assuming the bridge interface got an IP address, and that
> there is local multicast listener.
>
> Missing anything here?
Hm, for multi
On Sun, Mar 19, 2017 at 05:55:06PM +0100, Linus Lüssing wrote:
> On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote:
> > Wait.
> >
> > May this break local multicast listener that are bound to the bridge
> > interface? Assuming the bridge interface
PACKET_OTHERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing
---
Changelog v2:
* refrain from altering pkt_type for multicast packets
with a unicast destination MAC
---
net/bridge/br_input.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_inpu
On Tue, Mar 21, 2017 at 04:32:45PM -0700, Stephen Hemminger wrote:
> On Tue, 21 Mar 2017 23:28:45 +0100
> Linus Lüssing wrote:
>
> > However, the IP code drops it in the beginning of ip_input.c/ip_rcv()
> > as the dnat target did not update the skb->pkt_type. If after
&g
nning of ip_input.c/ip_rcv() as the dnat target left
the skb->pkt_type as PACKET_OTHERHOST.
Fixing this by resetting skb->pkt_type to an appropriate type after
dnat'ing.
Signed-off-by: Linus Lüssing
---
Changelog v3:
- moved pkt_type fixup into ebtable dnat code
-> v1/v
sending packets every 250ms for 600s, with a
"--limit 1/sec --limit-burst 50" rule and a command like this
in the background:
$ ebtables -N VOIDCHAIN
$ while true; do ebtables -F VOIDCHAIN; sleep 30; done
The results are:
Before: ~1600 packets
After: 650 packets
Signed-off-by: Linus Lüssing
Hi Pablo,
Thanks for your reply!
On Tue, Nov 28, 2017 at 12:30:08AM +0100, Pablo Neira Ayuso wrote:
> [...]
> > diff --git a/net/bridge/netfilter/ebt_limit.c
> > b/net/bridge/netfilter/ebt_limit.c
> > index 61a9f1be1263..f74b48633feb 100644
> > --- a/net/bridge/netfilter/ebt_limit.c
> > +++ b/ne
On Mon, Dec 04, 2017 at 05:53:35AM +0100, Linus Lüssing wrote:
> And so, no I do not have this patch. I looked at it now, but it
> does not seem to have any relation with .matchinfo, does it?
Relation between .usersize and .checkentry I ment, not
.usersize and .matchinfo.
On Thu, Dec 07, 2017 at 01:26:19AM +0100, Pablo Neira Ayuso wrote:
> > I also had a quick look at a 4.15-rc1 kernel in a VM now. I still
> > end up in ebt_limit_mt_check() with the variables being reset
> > when editing the table somewhere.
>
> My question is if your fix would work with 4.15-rc1.
On Fri, Dec 08, 2017 at 06:46:06AM +0100, Linus Lüssing wrote:
> Extending the usersize to include info->prev would probably be too
> hackish/ugly, right?
And wouldn't be enough anyway, since
info->{credit,credit_cap,cost} would still be zeroed... Hm.
On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> FullMAC WiFi chipset.
Hi Rafał,
Thanks for reporting this issue!
> Can you see any solution for this problem? Is that an option to stop
> multicast-to-unicast
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of
On Mon, Mar 12, 2018 at 12:08:56PM +0100, Linus Lüssing wrote:
> On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> > I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> > FullMAC WiFi chipset.
>
> Hi Rafał,
>
> Thanks for
ehavior to "xtables-nft-multi ebtables" which uses
nft_limit instead of ebt_limit. In tests nft_limit did not suffer from
this issue and rate limited to 650 just fine.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Linus Lüssing
---
Changelog v2:
- Adjusted commit messa
Even though RFC4541 recommends this, I'm not quite sure whether
this works... even for IGMP.
I think this would lead to multicast packet loss in a scenario
like this:
--
[Switch A] -- [Switch B]
/ /
/ /
Hi and thanks for your reply!
On Fri, Dec 14, 2018 at 10:32:16AM +0800, Ying Xu wrote:
> I think the scenario mentioned above is abnormal.
Can we agree, that this scenario, if switch A and B were using the
current bridge code, has issues right now which it did
not have before that patch?
I also
Hi,
This patchset adds initial Multicast Router Discovery support to
the Linux bridge (RFC4286). With MRD it is possible to detect multicast
routers and mark bridge ports and forward multicast packets to such routers
accordingly.
So far, multicast routers are detected via IGMP/MLD queries and PIM
potentially trimmed skb to
verfiy. However, there is no need to propagate it to the caller.
For the second and third case explicit IP packet length checks were
added.
This hopefully makes ip_mc_check_igmp() and ipv6_mc_check_mld() easier
to read and verfiy, as well as easier to use.
Signed-off-by: Linus
ify that length
checks are performed properly.
Signed-off-by: Linus Lüssing
---
net/ipv4/igmp.c| 51 ++---
net/ipv6/mcast_snoop.c | 62 --
2 files changed, 52 insertions(+), 61 deletions(-)
diff --git a/net/i
Otherwise other snooping switches might refrain from forwarding these
advertisements to us.
Signed-off-by: Linus Lüssing
---
include/uapi/linux/in.h | 9 +++---
net/bridge/br_multicast.c | 72 ++-
net/ipv6/mcast.c | 2 ++
3 files c
ssing adds such routers to the internal
multicast router list.
Signed-off-by: Linus Lüssing
---
include/linux/in.h | 5 +
include/net/addrconf.h | 15 +
include/uapi/linux/icmpv6.h | 2 ++
include/uapi/linux/igmp.h | 1 +
net/bridge/br_multicas
On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov wrote:
> Every user would expect to have traffic forwarded only to the configured
> mdb destination when snooping is enabled, instead now to get that one
> needs to enable both snooping and querier. Enabling querier on all
> switches cou
Hi Nik, hi Ido,
By the way speaking about the IGMP/MLD querier mechanism. Not sure if
you are subscribed to the p...@ietf.org or mcast-w...@ietf.org mailing lists.
There was a call for volunteers to progress IGMP/MLD to standards
track not that long ago:
"[pim] Volunteers needed for work on prog
On Sat, Feb 16, 2019 at 09:27:26PM +0200, niko...@cumulusnetworks.com wrote:
> >>The no querier condition is not currently reflected via switchdev, so
> >>the behavior you're proposing in your patch is what actually happens
> >in
> >>the data plane.
> >>
> >>We already hit the problem Linus mention
On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> This is v2 of the RFC patch which aims to forward packets to known
> mdsts' ports only (the no querier case). After v1 I've kept
> the previous behaviour when it comes to unregistered traffic or when
> a querier is present. All
On Tue, Feb 19, 2019 at 09:57:16AM +0100, Linus Lüssing wrote:
> On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> > This is v2 of the RFC patch which aims to forward packets to known
> > mdsts' ports only (the no querier case). After v1 I've kept
&
On Tue, Feb 19, 2019 at 03:31:42PM +0200, Nikolay Aleksandrov wrote:
> On 19/02/2019 11:21, Linus Lüssing wrote:
> > On Tue, Feb 19, 2019 at 09:57:16AM +0100, Linus Lüssing wrote:
> >> On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> >>> This is
On Sat, Jun 29, 2019 at 07:29:45PM +0300, Ido Schimmel wrote:
> I would like to avoid having drivers take the querier state into account
> as it will only complicate things further.
I absolutely share your pain. Initially in the early prototypes of
multicast awareness in batman-adv we did not cons
Hi Ido,
> Do you differentiate between IPv4 and IPv6 in batman-adv?
For most things, yes: The querier state is kept separately for
IPv4 and IPv6. And we do have something like a "router node"
flag to signalize that a node needs all multicast traffic, which
is split into IPv4 and IPv6.
The "MDB"
On Wed, Aug 14, 2019 at 12:58:58PM -0400, David Miller wrote:
> From: Stefano Brivio
> Date: Tue, 13 Aug 2019 00:46:01 +0200
>
> > Commit ba5ea614622d ("bridge: simplify ip_mc_check_igmp() and
> > ipv6_mc_check_mld() calls") replaces direct calls to pskb_may_pull()
> > in br_ipv6_multicast_mld2_r
On Wed, Aug 14, 2019 at 05:40:58PM +0100, Patrick Ruddy wrote:
> The group is being joined by MLD at the L3 level but the packets are
> not being passed up to the l3 interface becasue there is a MLD querier
> on the network
>
> snippet from /proc/net/igmp6
> ...
> 40 sw1 ff02
Is there anyone on the list who would like to fill out this
questionnaire on behave of the Linux bridge implementation?
Or maybe someone already did?
https://tools.ietf.org/html/draft-eckert-pim-igmp-mld-questionnaire-02
-> "Questionnaire for Vendors or Host Implementors"
I got an email that the
Lüssing -
Date: Tue, 24 Mar 2020 21:54:02 +0100
From: Linus Lüssing
To: mcast-w...@ietf.org, p...@ietf.org
Subject: [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...
Hi,
With Freifunk [0] we lately came across an annoying issue with Android
devices... which I'm not r
"Number of
Sources" field in the "Multicast Address Record" before reading it.
And not the size of a pointer to this field.
Fixes: e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2
report handling")
Signed-off-by: Linus Lüssing
---
net/bridge/
On Sun, Jul 05, 2020 at 09:33:13PM +0300, Nikolay Aleksandrov wrote:
> On 05/07/2020 21:22, Linus Lüssing wrote:
> > Commit e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in
> > igmp3/mld2 report handling") introduced a small bug which would potentially
>
mber of
Sources" field in the "Multicast Address Record" before reading it.
And not the size of a pointer to this field.
Fixes: e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2
report handling")
Acked-by: Nikolay Aleksandrov
Signed-off-by: Linus Lüs
On Sun, Jul 05, 2020 at 10:11:39PM +0300, Nikolay Aleksandrov wrote:
> On 7/5/20 10:08 PM, Linus Lüssing wrote:
> > On Sun, Jul 05, 2020 at 09:33:13PM +0300, Nikolay Aleksandrov wrote:
> > > On 05/07/2020 21:22, Linus Lüssing wrote:
> > > > Commit e57f61858b7c ("
On Sun, Jul 05, 2020 at 11:18:36PM +0300, Nikolay Aleksandrov wrote:
> > > By the way, I can't verify at the moment, but I think we can drop that
> > > whole
> > > hunk altogether since skb_header_pointer() is used and it will simply
> > > return
> > > an error if there isn't enough data for nsrc
the specific host(s).
Link: https://issuetracker.google.com/issues/149630944
Link: https://github.com/freifunk-gluon/gluon/issues/1832
Signed-off-by: Linus Lüssing
---
A version of this patch rebased to Linux 4.14 is currently applied on a
400 nodes mesh network (Freifunk Vogtland).
I'm aware
On Sun, Aug 16, 2020 at 03:08:13PM -0700, Stephen Hemminger wrote:
> Rather than adding yet another feature to the bridge, could this hack be done
> by
> having a BPF hook? or netfilter module?
Hi Stephen,
Thanks for the constructive feedback and suggestions!
The netfilter approach sounds tempt
On Tue, Sep 22, 2020 at 10:30:17AM +0300, Nikolay Aleksandrov wrote:
> From: Nikolay Aleksandrov
>
> Since now we have src in br_ip, u no longer makes sense so rename
> it to dst. No functional changes.
>
> v2: fix build with CONFIG_BATMAN_ADV_MCAST
Hi Nikolay,
I don't see a "src" in br_ip in
On Tue, Sep 22, 2020 at 07:51:19PM +0200, Linus Lüssing wrote:
> I don't see a "src" in br_ip in net-next/master at the moment. Or
> is that supposed to be added with your IGMPv3 implementation in
> the future?
Ah, sorry, found the according patch (*) it in my other inbox.
Hi,
I wanted to add the remaining pieces for batman-adv to support
IPv4 multicast groups in bridged setups, next to the IPv6 support
already in place. For which we'd need MRD support. So once more
I'd tap into the bridge for this information from batman-adv.
Then I realized again that the bridge
of the mrdisc tool
(https://github.com/troglobit/mrdisc).
Fixes: 4b3087c7e37f ("bridge: Snoop Multicast Router Advertisements")
Signed-off-by: Linus Lüssing
---
include/net/addrconf.h| 1 -
net/bridge/br_multicast.c | 33 -
net/ipv6/mcast_sn
Hi,
The following are two patches for the Linux bridge regarding multicast
routers. They are rebased on top of the following fix:
"net: bridge: mcast: fix broken length + header check for MRDv6 Adv." [0]
And should be applied afterwards.
The first one splits the so far combined multicast router s
include a multicast router timeout for both IPv4 and IPv6.
Signed-off-by: Linus Lüssing
---
include/uapi/linux/if_bridge.h | 2 +
net/bridge/br_forward.c| 22 ++-
net/bridge/br_input.c | 2 +-
net/bridge/br_mdb.c| 38 +++-
net/bridge/br_multicast.c | 341
bridge.
Signed-off-by: Linus Lüssing
---
include/linux/if_bridge.h | 8 ++
net/bridge/br_multicast.c | 58 +++
2 files changed, 66 insertions(+)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 2cc35038a8ca..12e9a32dbca0 100644
--- a
Hi,
The following are two patches for the Linux bridge regarding multicast
routers. They are rebased on top of the following fix:
"net: bridge: mcast: fix broken length + header check for MRDv6 Adv." [0]
And should be applied afterwards.
The first one splits the so far combined multicast router s
In preparation for the upcoming split of multicast router state into
their IPv4 and IPv6 variants and to avoid IPv6 #ifdef clutter later add
two wrapper functions for router node retrieval in the payload
forwarding code.
Signed-off-by: Linus Lüssing
---
net/bridge/br_forward.c | 15
able put one router port entry with both the IPv4 and IPv6
multicast router info later.
Signed-off-by: Linus Lüssing
---
net/bridge/br_mdb.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index
In preparation for the upcoming split of multicast router state into
their IPv4 and IPv6 variants and as the br_multicast_mark_router() will
be split for that remove the select querier wrapper and instead add
ip4 and ip6 variants for br_multicast_query_received().
Signed-off-by: Linus Lüssing
101 - 200 of 242 matches
Mail list logo
