Date:	Fri, 11 Jul 2008 15:27:58 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	davem@...emloft.net, jmorris@...ei.org, kaber@...sh.net,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	netdev@...r.kernel.org, pekkas@...core.fi, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from
	unjoined groups

On Fri, Jul 11, 2008 at 12:00:57PM -0700, David Stevens wrote:
> Yes, that's me, and that's also true. It wasn't the address, it's the time 
> delay. I think that
> was months ago. But you left out a distinguishing piece in your example 
> here, which is
> all the difference.
> 
> Joins are also per-interface. So, joining a group on "lo" does not join 
> the group on
> "eth0". In your example below (4), the reason it won't receive the packets 
> is because
> the machine is not a group member on eth0. If any process joined the group 
> on eth0
> then an INADDR_ANY-bound socket would receive them (whether it joined or 
> not).
> I guess I wasn't clear -- the reason you have to join below is to 
> guarantee someone
> has joined. If some other process already joined on that interface, you 
> would
> receive them also.
> 
>                                                                 +-DLS
> 
> Neil Horman <nhorman@...driver.com> wrote on 07/11/2008 11:23:04 AM:
> 
> > 
> > >>>
> > >>> 4) Finally, what if process B bound itself to INADDR_ANY rather than 
> to
> > >>>the
> > >>> specific multicast group.  Should it see process A's sent frames 
> then?
> > >>
> > >>        Not if the group membership is on lo and the sends are on 
> eth0.
> > >>The
> > >>reason it isn't seeing the packets is not the binding, but the group
> > >>membership. To hear packets you're sending out an interface, you must
> > >>join that group on that interface *and* the sender must allow loopback 
> by
> > >>not clearing IP_MULTICAST_LOOP. Joining the group on a different 
> interface
> > >>really is joining a different group, as far as multicasting is 
> concerned.
> > 
> > >         But in the sentence above, I think you missed the point of the
> > > mail I sent before. Joining a group or not on a particular socket has
> > > nothing at all to do with delivery of multicasts to the socket.
> > > 
> > >         Multicast addresses, like unicast addresses, are for the 
> entire
> > > machine, not just the socket that does the join. If anyone on the
> > > machine has joined the group and your binding matches the packet, you
> > > will receive a copy. That's intentional. If you don't join any groups
> > > at all, but bind to INADDR_ANY, you will receive packets for the port
> > > and protocol and any local unicast or multicast address (including
> > > groups joined by any other process on the machine).
> > > 
> > >  +-DLS
> > 
> > If thats the final word, then I'll believe you, but it seems to me that
> > receiving multicast traffic on a socket that didn't specifically join a
> > multicast group is asking for trouble, as every application needs to be 
> prepared
> > to handle data payloads it was not expected to recieve.
> > 
> > Can you clarify your statement above with the one that I copied in from 
> you
> > earlier?
> > 
> > Regards
> > Neil
> > 
> > 
> > -- 
> > /****************************************************
> >  * Neil Horman <nhorman@...driver.com>
> >  * Software Engineer, Red Hat
> >  ****************************************************/


Alright, we'll it sounds like this has been well thought out, and my
understanding is in the wrong.  Patch rescinded. Sorry for the noise.

Best
Neil

-- 
/****************************************************
 * Neil Horman <nhorman@...driver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists