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;
From:   Callum Sinclair <Callum.Sinclair@alliedtelesis.co.nz>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     "dsahern@kernel.org" <dsahern@kernel.org>,
        "nikolay@nvidia.com" <nikolay@nvidia.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linus.luessing@c0d3.blue" <linus.luessing@c0d3.blue>
Subject: Re: [PATCH 1/1] net: Allow all multicast packets to be received on a
 interface.
Thread-Topic: [PATCH 1/1] net: Allow all multicast packets to be received on a
 interface.
Thread-Index: AQHXY15AjPZKD1gBPUW680Mm+Pg7t6sXd18AgAFtyb4=
Date:   Fri, 18 Jun 2021 00:09:48 +0000
Message-ID: <1623974988948.39187@alliedtelesis.co.nz>
References: <20210617095020.28628-1-callum.sinclair@alliedtelesis.co.nz>
 <20210617095020.28628-2-callum.sinclair@alliedtelesis.co.nz>,<YMtZspsYH0wd9SVf@lunn.ch>
In-Reply-To: <YMtZspsYH0wd9SVf@lunn.ch>
Accept-Language: en-US, en-NZ
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Hi Andrew=0A=
=0A=
> What is the big picture here? Are you trying to move the snooping=0A=
> algorithm into user space? User space will then add/remove Multicast=0A=
> FIB entries to the bridge to control where mulitcast frames are sent?=0A=
=0A=
Yes I want to run a IGMP, MLD and PIM implementation in userspace and=0A=
just use the kernel to send multicast frames to addresses that have been=0A=
installed into the multicast forwarding cache.=0A=
=0A=
> In the past i have written a multicast routing daemon. It is a similar=0A=
> problem. You need access to all the join/leaves. But the stack does=0A=
> provide them, if you bind to the multicast routing socket. Why not use=0A=
> that mechanism? Look in the mrouted sources for an example.=0A=
=0A=
Ah I can see that I get the IGMP and MLD packets now. I was just creating=
=0A=
the socket as a IP socket without multicast routing. Thanks for your help.=
=0A=
=0A=
Cheers=0A=
Callum=0A=
________________________________________=0A=
From: Andrew Lunn <andrew@lunn.ch>=0A=
Sent: Friday, June 18, 2021 2:18 AM=0A=
To: Callum Sinclair=0A=
Cc: dsahern@kernel.org; nikolay@nvidia.com; netdev@vger.kernel.org; linux-k=
ernel@vger.kernel.org; linus.luessing@c0d3.blue=0A=
Subject: Re: [PATCH 1/1] net: Allow all multicast packets to be received on=
 a interface.=0A=
=0A=
On Thu, Jun 17, 2021 at 09:50:20PM +1200, Callum Sinclair wrote:=0A=
> To receive IGMP or MLD packets on a IP socket on any interface the=0A=
> multicast group needs to be explicitly joined. This works well for when=
=0A=
> the multicast group the user is interested in is known, but does not=0A=
> provide an easy way to snoop all packets in the http://scanmail.trustwave=
.com/?c=3D20988&d=3DwNnL4EU-bOXOuxnfu9BLng8ncWxDIw3ACrur9S2N4w&u=3Dhttp%3a%=
2f%2f224%2e0%2e0%2e0%2f8 or the=0A=
> FF00::/8 range.=0A=
>=0A=
> Define a new sysctl to allow a given interface to become a IGMP or MLD=0A=
> snooper. When set the interface will allow any IGMP or MLD packet to be=
=0A=
> received on sockets bound to these devices.=0A=
=0A=
Hi Callum=0A=
=0A=
What is the big picture here? Are you trying to move the snooping=0A=
algorithm into user space? User space will then add/remove Multicast=0A=
FIB entries to the bridge to control where mulitcast frames are sent?=0A=
=0A=
In the past i have written a multicast routing daemon. It is a similar=0A=
problem. You need access to all the join/leaves. But the stack does=0A=
provide them, if you bind to the multicast routing socket. Why not use=0A=
that mechanism? Look in the mrouted sources for an example.=0A=
=0A=
     Andrew=0A=