| 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
| ||
|
Date: Sat, 26 Aug 2023 14:55:53 +0000
From: caskd <caskd@...xen.eu>
To: Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov
<razor@...ckwall.org>
Cc: netdev@...r.kernel.org
Subject: IPv6 multicast and snooping on bridges
Hello everyone,
i've noticed that the bridges and IPv6 multicast snooping doesn't seem to play out together well. When a address gets assigned to the bridge it gets entered into it's bridge multicast database but it vanishes after a while. I wasn't able to pinpoint the cause of the vanish, it's not the GC.
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?
Thanks in advance.
--
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/
Download attachment "signature.asc" of type "application/pgp-signature" (859 bytes)
Powered by blists - more mailing lists