From owner-svn-src-all@FreeBSD.ORG Thu Mar 31 18:18:33 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DFD10656DE; Thu, 31 Mar 2011 18:18:33 +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 BC8C08FC27; Thu, 31 Mar 2011 18:18:33 +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 34BFA46B1A; Thu, 31 Mar 2011 14:18:33 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 94B358A027; Thu, 31 Mar 2011 14:18:32 -0400 (EDT) From: John Baldwin To: Randall Stewart Date: Thu, 31 Mar 2011 14:17:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103291401.03565.jhb@freebsd.org> <2BE17525-83AA-4255-B191-3429B5FF6F5E@lakerest.net> In-Reply-To: <2BE17525-83AA-4255-B191-3429B5FF6F5E@lakerest.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103311417.27360.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 31 Mar 2011 14:18:32 -0400 (EDT) Cc: svn-src-head@freebsd.org, Daniel Eischen , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217592 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:18:34 -0000 On Thursday, March 31, 2011 11:40:08 am Randall Stewart wrote: > John: > > So I caught up with Dave Thaler here at the IETF... > > He said that NO UDP socket that has NOT joined a multicast > group should ever receive a packet sent to a multicast address. > He also said this was part of the POSIX API and the way > all Unix machines worked. > > So.. no it is a bug and the fix is correct. That works for me. Can you please merge this fix to 7 and 8? > R > On Mar 29, 2011, at 2:01 PM, John Baldwin wrote: > > > On Wednesday, January 19, 2011 2:07:16 pm Randall Stewart wrote: > >> Author: rrs > >> Date: Wed Jan 19 19:07:16 2011 > >> New Revision: 217592 > >> URL: http://svn.freebsd.org/changeset/base/217592 > >> > >> Log: > >> Fix a bug where Multicast packets sent from a > >> udp endpoint may end up echoing back to the sender > >> even with OUT joining the multi-cast group. > >> > >> Reviewed by: gnn, bms, bz? > >> Obtained from: deischen (with help from) > >> > >> Modified: > >> head/sys/netinet/udp_usrreq.c > >> > >> Modified: head/sys/netinet/udp_usrreq.c > >> > > ============================================================================== > >> --- head/sys/netinet/udp_usrreq.c Wed Jan 19 18:20:11 2011 (r217591) > >> +++ head/sys/netinet/udp_usrreq.c Wed Jan 19 19:07:16 2011 (r217592) > >> @@ -479,11 +479,13 @@ udp_input(struct mbuf *m, int off) > >> * and source-specific multicast. [RFC3678] > >> */ > >> imo = inp->inp_moptions; > >> - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && > >> - imo != NULL) { > >> + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { > >> struct sockaddr_in group; > >> int blocked; > >> - > >> + if(imo == NULL) { > >> + INP_RUNLOCK(inp); > >> + continue; > >> + } > >> bzero(&group, sizeof(struct sockaddr_in)); > >> group.sin_len = sizeof(struct sockaddr_in); > >> group.sin_family = AF_INET; > > > > So it turns out that this is a feature, not a bug, and is how multicast has > > always worked. Specifically, if you bind a UDP socket with a wildcard > > address, it should receive all traffic for the bound port, unicast or > > multicast. When you join a group, you have switched the socket into a mode > > where it now has a whitelist of acceptable multicast groups, but if a socket > > has no joined groups, it should receive all multicast traffic, not none. This > > change breaks that. > > > > I did not find this behavior intuitive at first, but it does seem to be > > required. Note the description of IP_ADD_MEMBERSHIP from RFC 3678 for > > example: > > > > 3. Overview of APIs > > > > There are a number of different APIs described in this document that > > are appropriate for a number of different application types and IP > > versions. Before providing detailed descriptions, this section > > provides a "taxonomy" with a brief description of each. > > > > There are two categories of source-filter APIs, both of which are > > designed to allow multicast receiver applications to designate the > > unicast address(es) of sender(s) along with the multicast group > > (destination address) to receive. > > > > o Basic (Delta-based): Some applications desire the simplicity of > > a delta-based API in which each function call specifies a > > single source address which should be added to or removed from > > the existing filter for a given multicast group address on > > which to listen. Such applications typically fall into either > > of two categories: > > > > + Any-Source Multicast: By default, all sources are accepted. > > Individual sources may be turned off and back on as needed > > over time. This is also known as "exclude" mode, since the > > source filter contains a list of excluded sources. > > > > + Source-Specific Multicast: Only sources in a given list are > > allowed. The list may change over time. This is also known > > as "include" mode, since the source filter contains a list > > of included sources. > > > > This API would be used, for example, by "single-source" > > applications such as audio/video broadcasting. It would > > also be used for logical multi-source sessions where each > > source independently allocates its own Source-Specific > > Multicast group address. > > > > > > ..... > > > > 4.1.1. IPv4 Any-Source Multicast API > > > > The following socket options are defined in for > > applications in the Any-Source Multicast category: > > > > Socket option Argument type > > IP_ADD_MEMBERSHIP struct ip_mreq > > IP_BLOCK_SOURCE struct ip_mreq_source > > IP_UNBLOCK_SOURCE struct ip_mreq_source > > IP_DROP_MEMBERSHIP struct ip_mreq > > > > IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP are already implemented on > > most operating systems, and are used to join and leave an any-source > > group. > > > > IP_BLOCK_SOURCE can be used to block data from a given source to a > > given group (e.g., if the user "mutes" that source), and > > IP_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then > > "unmutes" the source). > > > > 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. > > > > -- > > John Baldwin > > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > > -- John Baldwin