Date: Wed, 30 Mar 2011 11:23:13 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, Randall Stewart <rrs@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217592 - head/sys/netinet Message-ID: <Pine.GSO.4.64.1103301114270.360@sea.ntplx.net> In-Reply-To: <201103300827.25260.jhb@freebsd.org> References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103291401.03565.jhb@freebsd.org> <Pine.GSO.4.64.1103300343310.28776@sea.ntplx.net> <201103300827.25260.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Mar 2011, John Baldwin wrote: > On Wednesday, March 30, 2011 3:50:18 am Daniel Eischen wrote: >> On Tue, 29 Mar 2011, John Baldwin wrote: >>> >>> As to why the packets loop back to the receiver, I believe that is a separate >>> issue on the output side, not the receive side. >> >> That may be, but the behavior is undesired if the no process >> on the system has joined the multicast group. I believe it >> was broke with r189359, and the comment in the code that broke >> it says: >> >> /* >> * Loop back multicast datagram if not expressly >> * forbidden to do so, even if we are not a member >> * of the group; ip_input() will filter it later, >> * thus deferring a hash lookup and mutex acquisition >> * at the expense of a cheap copy using m_copym(). >> */ >> >> The previous revision did a lookup of the multicast address >> and looped it if an entry was found for it. > > Well, for one, this patch changes the behavior even if there is a socket > joined to the group. Yes, I understand that. But before this patch, the behavior was correct for what you have stated, and for my particular case. When we fixed the problem, we took BMS' comment as guidance and filtered on the input side. > However, I suspect that in your case your app should > probably be turning IP_MULTICAST_LOOP off explicitly regardless of what the > changes end up being (or do you write to multiple groups and want a subset > of those groups to loop back?). In the _absence_ of setting multicast loopback on the socket, we should not be getting looped-back packets. This is the behavior we've seen on other OS's. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1103301114270.360>