From owner-svn-src-head@FreeBSD.ORG Wed Mar 30 18:27:51 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860B81065676; Wed, 30 Mar 2011 18:27:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 585E58FC1C; Wed, 30 Mar 2011 18:27:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EB45546B06; Wed, 30 Mar 2011 14:27:50 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 76E258A01B; Wed, 30 Mar 2011 14:27:50 -0400 (EDT) From: John Baldwin To: Daniel Eischen Date: Wed, 30 Mar 2011 13:59:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103300823.53986.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103301359.37444.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 30 Mar 2011 14:27:50 -0400 (EDT) Cc: svn-src-head@freebsd.org, George Neville-Neil , svn-src-all@freebsd.org, src-committers@freebsd.org, Randall Stewart Subject: Re: svn commit: r217592 - head/sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:27:51 -0000 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