netdev - Re: VLAN aware bridge multicast and quierer problems

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: <5f483469-fba4-4f43-a51a-66c267126709@blackwall.org>
Date: Wed, 13 Mar 2024 18:03:31 +0200
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Andrew Lunn <andrew@...n.ch>, Ido Schimmel <idosch@...dia.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: VLAN aware bridge multicast and quierer problems

On 3/13/24 17:40, Andrew Lunn wrote:
> Hi Nikolay, Ido
> 
> I have a colleague who is using a VLAN aware bridge with
> multicast. IGMP snooping is causing problems in this setup. The setup
> periodically sends IPv6 router solicitations towards the router and
> expects router advertisements back. After a while, the router
> solicitations were no longer forwarded/flooded by the bridge.
> 
> The bridge doesn't drop the RS frames, but instead of forwarding them
> using br_flood(), it calls br_mulricast_flood() with an empty
> destination list. MC snooping is on by default and is VLAN-aware by
> default, so it should work in this context. If he disable it for
> testing purposes, the RS get forwarded.
> 
> We then checked how the destination list gets computed. Not very
> surprisingly, this is based on MC group membership reports in
> combination with MC querier tracking (no querier -> no MC snooping,
> i.e. br_flood() instead of br_multicast_flood()). So far, so good. We
> don't have a querier on the VLAN in question but we do have one on
> another VLAN running over the same bridge. And then he noticed that
> br_multicast_querier_exists() which is called by
> br_handle_frame_finish() to decide whether it can rely on snooped MC
> groups doesn't get any VLAN information, only the global bridge
> multicast context. So it can't possibly know whether there's a querier
> on the VLAN the frame to be forwarded is on. As soon as there's a
> querier on one VLAN, the code seems to assume that there are queriers
> on all of them. And on those without an actual querier, this means
> that destination lists are empty because there are no membership
> reports on these VLANs (at least not after the initial reports right
> after joining a group).
> 
> It seems odd that you spent a lot of time adding code to track group
> memberships by VLAN but then left our the last tiny bit to also track
> queriers by VLAN? So we are wondering if we are missing something,
> some configuration somewhere?
> 
> We have a test script which sets up a bridge in a network name space,
> and uses scapy and tcpdump to show the problem. I can send it to you
> if you are interested.
> 
> Thanks
> 	Andrew

Hi Andrew,
Please check again, br_multicast_rcv() which is called before
br_multicast_querier_exists() should set brmctx and pmctx to
the proper vlan contexts. If vlan igmp snooping is enabled then
the call to br_multicast_querier_exists() is done with the vlan's
contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
enabled by default).

Cheers,
  Nik