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] [thread-next>] [day] [month] [year] [list]

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

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

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