Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 17 Jun 2021 16:18:26 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
Cc:     dsahern@kernel.org, nikolay@nvidia.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linus.luessing@c0d3.blue
Subject: Re: [PATCH 1/1] net: Allow all multicast packets to be received on a
 interface.
Message-ID: <YMtZspsYH0wd9SVf@lunn.ch>
References: <20210617095020.28628-1-callum.sinclair@alliedtelesis.co.nz>
 <20210617095020.28628-2-callum.sinclair@alliedtelesis.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210617095020.28628-2-callum.sinclair@alliedtelesis.co.nz>
Precedence: bulk

On Thu, Jun 17, 2021 at 09:50:20PM +1200, Callum Sinclair wrote:
> To receive IGMP or MLD packets on a IP socket on any interface the
> multicast group needs to be explicitly joined. This works well for when
> the multicast group the user is interested in is known, but does not
> provide an easy way to snoop all packets in the 224.0.0.0/8 or the
> FF00::/8 range.
> 
> Define a new sysctl to allow a given interface to become a IGMP or MLD
> snooper. When set the interface will allow any IGMP or MLD packet to be
> received on sockets bound to these devices.

Hi Callum

What is the big picture here? Are you trying to move the snooping
algorithm into user space? User space will then add/remove Multicast
FIB entries to the bridge to control where mulitcast frames are sent?

In the past i have written a multicast routing daemon. It is a similar
problem. You need access to all the join/leaves. But the stack does
provide them, if you bind to the multicast routing socket. Why not use
that mechanism? Look in the mrouted sources for an example.

     Andrew