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

Message-ID: <123ce9de-7ca1-4380-891b-cdbab4c4a10b@lunn.ch>
Date: Wed, 13 Mar 2024 16:40:43 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Nikolay Aleksandrov <razor@...ckwall.org>,
	Ido Schimmel <idosch@...dia.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: VLAN aware bridge multicast and quierer problems

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