Date: Wed, 30 Mar 2011 13:59:37 -0400 From: John Baldwin <jhb@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: svn-src-head@freebsd.org, George Neville-Neil <gnn@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Randall Stewart <rrs@lakerest.net> Subject: Re: svn commit: r217592 - head/sys/netinet Message-ID: <201103301359.37444.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.64.1103301126120.360@sea.ntplx.net> References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103300823.53986.jhb@freebsd.org> <Pine.GSO.4.64.1103301126120.360@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, March 30, 2011 11:42:01 am Daniel Eischen wrote: > > BMS preserved this behavior and your patch changes > > But he changed the behavior on output. Pre-BMS and post-BMS > behave differently and not like Solaris 10 or VxWorks. Haven't > tried Linux. Yes, I am not debating that. I'm merely talking about the input side. > > it. UDP sockets start off with inp_moptions == NULL, so if you never do any > > multicast-related setsockopt() you will receive all matching multicast packets. > > However, once you do any multicast-related setsockopt() (IP_MULTICAST_LOOP, > > IP_ADD_MEMBERSHIP, etc.) then inp_moptions is allocated and is non-NULL. > > At that point it only accepts packets that match, except that even then we > > used a sysctl which defaulted to off (!) to see if we should check the list of > > memberships (net.inet.udp.strict_mcast_mship). This options structure was never > > free'd, however, so you could get the truly bizarre behavior of: > > > > - bind a new socket, it will not receive all matching multicast traffic > > - use IP_ADD_MEMBERSHIP to add a group, it will now receive only matching multicast > > traffic for the group > > - use IP_DROP_MEMBERSHIP to remove the group, it will now receive no multicast > > traffic > > > > The different behavior in states 1 and 3 I find confusing and odd. By default > > all sockets just always received all matching multicast traffic though. :) > > Not if a multicast group was not joined. The pre-BMS changes > did not loop back multicast packets in ip_output.c. Well, they would receive all multicast traffic that wasn't loopback traffic. That is, if I had two sockets bound to *:2000 and *:4000 and one socket joined a group 224.1.2.3, then both sockets would receive traffic bound for 224.1.2.3 if it matched their ports in both the pre-BMS code and in post-BMS but pre-RRS. Now only the socket that did the join will receive the packets, so it is a change in behavior. Now I find this unintuitive, but other folks I have talked to have pointed out that that could be a valid interpretation of binding to INADDR_ANY. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103301359.37444.jhb>