netdev - Re: IPv6 multicast and snooping on bridges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <3L9Q6VZGO0Y2L.3LBULT0Z6RO3M@unix.is.love.unix.is.life>
Date: Sun, 27 Aug 2023 10:24:22 +0000
From: caskd <caskd@...xen.eu>
To: caskd <caskd@...xen.eu>
Cc: Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov
 <razor@...ckwall.org>, netdev@...r.kernel.org
Subject: Re: IPv6 multicast and snooping on bridges

caskd <caskd@...xen.eu> wrote:
> Hello everyone,
> 
> > How to reproduce:
> > 
> > - Create a bridge
> > - Activate multicast snooping
> > - Assign a address to the bridge
> > - Watch multicast database (especially the ones with the device and port both being the bridge)
> > - Wait 5-10 minutes (i wasn't able to pinpoint a exact interval but it usually happens in this timeframe)
> > 
> > During the waiting timeframe the interface's own host groups should disappear from the bridge's database, resulting in the bridge not accepting any more packets for it's own group.
> > 
> > Is this intended behaviour? It would seem like the interface can be used as a "switch-port" itself instead of configuring a dummy interface to be a part of the bridge, as it behaves correctly except for this one case. This isn't a problem in the IPv4 world but creates routing problems in the IPv6 world. If it is, could this be documented somewhere?
> 
> After some futher investigation, i noticed i can only replicate this when there is a VLAN interface as part of the bridge that is up. As soon as the interface goes up, it takes a bit and then the entries get deleted. I can replicate this on 6.4 just fine while i cannot replicate it in 5.19, so it seems to be something that used to work and broke during this period. I will build older kernels and try to pinpoint the breaking change(s).
>
Nevermind, found the trigger being the temporary entry lifetime and it also happens without a VLAN. So it seems to be a feature? Why would own multicast groups expire on a bridge that does snooping?

How to reproduce:

ip link add dummy-slave type dummy
ip link add bridge-dummy type bridge mcast_snooping 1
ip link set dev dummy-slave master bridge-dummy up
ip link set dev bridge-dummy up

# Watch as the timer goes down and own entries disappear
watch -n0.2 -d -x bridge -d -s mdb

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/


Download attachment "signature.asc" of type "application/pgp-signature" (859 bytes)