From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 17:12:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7058216A4B3 for ; Tue, 21 Oct 2003 17:12:40 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B20943FAF for ; Tue, 21 Oct 2003 17:12:39 -0700 (PDT) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9M0CdTi002466 for ; Tue, 21 Oct 2003 17:12:39 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com ; Tue, 21 Oct 2003 17:12:08 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h9M0CCww020779; Tue, 21 Oct 2003 17:12:12 -0700 (PDT) In-Reply-To: References: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22-427528834; protocol="application/pkcs7-signature" Message-Id: <71E524D5-0424-11D8-8EA7-000A95B9474C@apple.com> From: Joshua Graessley Date: Tue, 21 Oct 2003 17:12:38 -0700 To: "William A.Carrel" X-Mailer: Apple Mail (2.606) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: setsockopt IP_ADD_MEMBERSHIP not honored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 00:12:40 -0000 --Apple-Mail-22-427528834 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sounds good to me :) At the very least, this would improve the performance of the mDNSResponder. mDNSResponder has some additional code to get the interface the packet was received on so it can filter out the packet if it wasn't received on the interface that socket is bound to/associated with. This results in a packet being copied multiple times (once for every mDNSResponder socket) from the kernel to user space only to have all but one of those packets discarded. -josh On Oct 21, 2003, at 2:02 PM, William A.Carrel wrote: >> Some applications may rely on this behavior, so it might be unwise to >> change it. If you're going to make this change, you should probably >> make it some sort of socket option that applications can opt in to on >> a per socket basis. > > Relying on this behavior doesn't seem to make sense. It would be > relying on the kernel to let other programs to make you receive > unintended multicast packets. It would also be relying on behavior > contrary to the documentation. > > The only change in behavior would be if the program presumes someone > else is holding memberships on all the interfaces (on its behalf) so > it only has to open one. For example, in the case of multicast DNS, > if the program is really wanting to listen for mDNS traffic on all > interfaces, it needs to be adding membership on all interfaces. It > would be broken behavior on the part of the application to add > membership to the multicast address on one interface and trust that > someone else has memberships to that multicast address on all the > other interfaces, so it can get the multicast traffic for all > interfaces. The example code from Apple in > mDNSResponder-58/mDNSPosix/mDNSPosix.c (SetupSocket() at line 464) > also seems to acknowledge that the multicast socket is only handling > multicast for a specific interface. > > If a program really wants to get the multicast traffic on all > interfaces, then it needs to add membership for all the interfaces. > And if it holds membership on all the interfaces, my suggested fix > will not keep it from receiving the packets that it wants destined for > it. As such, I don't see the potential for a POLA violation in the > suggested fix. > > From the manpage: > A host must become a member of a multicast group before it can > receive > datagrams sent to the group. To join a multicast group, use the > IP_ADD_MEMBERSHIP option: > > struct ip_mreq mreq; > setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); > > where mreq is the following structure: > > struct ip_mreq { > struct in_addr imr_multiaddr; /* multicast group to join */ > struct in_addr imr_interface; /* interface to join on */ > } > > imr_interface should be INADDR_ANY to choose the default > multicast inter- > face, or the IP address of a particular multicast-capable > interface if > the host is multihomed. Membership is associated with a single > inter- > face; programs running on multihomed hosts may need to join the > same > group on more than one interface. Up to IP_MAX_MEMBERSHIPS > (currently > 20) memberships may be added on a single socket. > > The assertion that "membership is associated with a single interface" > is false under the current implementation. Membership is, at the > moment, associated with the interface you specified to join on, and > any other interfaces that any other processes on the entire system > (possibly even processes in jails) have joined the same multicast > address on. > > W. Richard Stevens wrote similarly on page 496 of UNP Vol. 1 (2nd > ed.). "Join a multicast group on a specified local interface. ... If > the local interface is specified as the wildcard address (INADDR_ANY > for IPv4)..., then the local interface is chosen by the kernel. ... > More than one join is allowed on a given socket... This can be used > on a multihomed host where, for example, one socket is created and > then for each interface a join is performed for a given multicast > address." > > It seems odd that someone would join on a specified local interface > and then start receiving packets on from an interface other than the > one they had specified. The descriptions given both by Stevens, by > Apple's mDNS example code and in the ip(4) man page run counter to the > current behavior, hence the code I presented a moment ago to bring the > behavior in line with the documentation. > --Apple-Mail-22-427528834--