From owner-svn-src-all@FreeBSD.ORG Wed Mar 30 08:07:25 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 6B7821065670; Wed, 30 Mar 2011 08:07:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 383B98FC08; Wed, 30 Mar 2011 08:07:24 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p2U7oIFt015208; Wed, 30 Mar 2011 03:50:18 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 30 Mar 2011 03:50:18 -0400 (EDT) Date: Wed, 30 Mar 2011 03:50:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201103291401.03565.jhb@freebsd.org> Message-ID: References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103291401.03565.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Randall Stewart , 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 Reply-To: Daniel Eischen 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: Wed, 30 Mar 2011 08:07:25 -0000 On Tue, 29 Mar 2011, 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. 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. -- DE