On Wed, Sep 17, 2025 at 02:30:51PM +0300, Ido Schimmel wrote: > But before making changes, I want to better understand the problem you > are seeing. Is it specific to the offloaded data path? I believe the > problem was fixed in the software data path by this commit:
Two issues I noticed recently, even without any hardware switch offloading, on plain soft bridges: 1) (Probably not the issue here? But just to avoid that this causes additional confusion:) we don't seem to properly converge to the lowest MAC address, which is a bug, a violation of the RFCs. If we received an IGMP/MLD query from a foreign host with an address like fe80::2 and selected it and then enable our own multicast querier with a lower address like fe80::1 on our bridge interface for example then we won't send our queries, won't reelect ourself. If I recall correctly. (Not too critical though, as at least we have a querier on the link. But I find the election code a bit confusing and I wouldn't dare to touch it without adding some tests.) 2) Without Ido's suggested workaround when the bridge multicast snooping + querier is enabled before the IPv6 DAD has taken place then our first IGMP/MLD query will fizzle, not be transmitted. However (at least for a non-hardware-offloaded) bridge as far as I recall this shouldn't create any multicast packet loss and should operate as "normal" with flooding multicast data packets first, with multicast snooping activating on multicast data after another IGMP/MLD querier interval has elapsed (default: 125 sec.)? Which indeed could be optimized and is confusing, this delay could be avoided. Is that that the issue you mean, Joseph? (I'd consider it more an optimization, so for net-next, not net though.) > In current implementation, :: always wins the election That would be news to me. RFC2710, section 5: To be valid, the Query message MUST come from a link- local IPv6 Source Address RFC3810, section 5.1.14, is even more explicit: 5.1.14. Source Addresses for Queries All MLDv2 Queries MUST be sent with a valid IPv6 link-local source address. If a node (router or host) receives a Query message with the IPv6 Source Address set to the unspecified address (::), or any other address that is not a valid IPv6 link-local address, it MUST silently discard the message and SHOULD log a warning. So :: can't be used as a source address for an MLD query. And since 2014 with "bridge: multicast: add sanity check for query source addresses" (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6565b9eeef194afbb3beec80d6dd2447f4091f8c) we should be adhering to that requirement? Let me know if I'm missing something. For IPv4 and 0.0.0.0 this is a different story though... I'm not aware of a requirement in RFCs to avoid 0.0.0.0 in IGMP queries. And "intuitively" one would prefer 0.0.0.0 to be the least prefered querier address. But when taking the IGMP RFCs literally then 0.0.0.0 would be the lowest one and always win... And RFC4541 unfortunately does not clarify the use of 0.0.0.0 for IGMP queries. Not quite sure what the common practice among other layer 2 multicast snooping implemetations across other vendos is. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0888d5f3c0f183ea6177355752ada433d370ac89 > > And Linus is working [1][2] on reflecting it to device drivers so that > the hardware data path will act like the software data path and flood > unregistered multicast traffic to all the ports as long as no querier > was detected. Right, for hardware offloading bridges/switches I'm on it, next revision shouldn't take much longer... Regards, Linus
