linux-kernel - Re: [RFC PATCH v2] net: bridge: igmp: Extend IGMP query to be per vlan

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

Message-ID: <87czxxvtwa.fsf@gmail.com>
Date:   Fri, 22 Jan 2021 17:05:57 +0100
From:   Joachim Wiberg <troglobit@...il.com>
To:     Nikolay Aleksandrov <nikolay@...dia.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        davem@...emloft.net, kuba@...nel.org, roopa@...dia.com,
        allan.nielsen@...rochip.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org
Subject: Re: [RFC PATCH v2] net: bridge: igmp: Extend IGMP query to be per vlan

On Mon, Jan 18, 2021 at 13:53, Nikolay Aleksandrov <nikolay@...dia.com> wrote:
> On 16/01/2021 17:39, Joachim Wiberg wrote:
>> We have discussed at length at work if an IGMP snooping implementation
>> really belongs in the bridge, or if it's better suited as a user space
>> daemon?  Similar to what was decided for RSTP/MSTP support, i.e., the
>> bridge only has STP and RSTP/MSTP is handled by mstpd[2].
>> 
>> Most of what's required for a user space implementation is available,
>> but it would've been nice if a single AF_PACKET socket on br0 could be
>> used to catch what brport (ifindex) a query or report comes in on.  As
>> it is now that information is lost/replaced with the ifindex of br0.
>> And then there's the issue of detecting and forwarding to a multicast
>> routing daemon on top of br0.  That br0 is not a brport in the MDB, or
>> that host_joined cannot be set/seen with iproute2 is quite limiting.
>> These issues can of course be addressed, but are they of interest to
>> the community at large?
>> 
>> [1]: https://lore.kernel.org/netdev/20180418120713.GA10742@troglobit/
>> [2]: https://github.com/mstpd/mstpd

Ni Nik,

> I actually had started implementing IGMPv3/MLDv2 as a user-space daemon part of
> FRRouting (since it already has a lot of the required infra to talk to the kernel).
> It also has IGMPv3/MLDv2 support within pimd, so a lot of code can be shared.

Interesting!  Glad to hear other people have had similar ideas :)

> Obviously there are pros and cons to each choice, but I'd be interested to see a
> full user-space implementation. I decided to make the kernel support more complete
> since it already did IGMPv2 and so stopped with the new FRR daemon.

Yeah it's difficult to find the right cut-off for when it'll be more
useful to do it all in userspace.  For us I think it was the combination
of having many VLANs and wanting full querier support, i.e., not having
any multicast router available.  When we had to go dumpster diving for
useful IP address in IGMP queries on higher-level VLAN interfaces.

> If needed I'd be happy to help with the kernel support for a new
> user-space daemon, and also can contribute to the daemon itself if
> time permits.

That's good to know.  I think I'll start breathing life into a small
IGMP-only (for now) userspace daemon and see where it leads.  I need
it both for work and for all the various multicast routing projects
I maintain on my spare time.

Would it be OK to send questions regarding issues interfacing with the
bridge and updates/progress to this list for such a project?

Best regards
 /Joachim