Date: Wed, 30 Mar 2011 07:27:36 -0400 From: Randall Stewart <rrs@lakerest.net> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, Daniel Eischen <deischen@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r217592 - head/sys/netinet Message-ID: <99FEFE99-455A-4A28-8C02-08DFAD28B6CD@lakerest.net> In-Reply-To: <201103291401.03565.jhb@freebsd.org> References: <201101191907.p0JJ7GMp086060@svn.freebsd.org> <201103291401.03565.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John: The original complaint on this came from Daniel... I believe he claimed that up until bms's multi-cast work.. you would NOT get a packet sent to you if you did not join the multi-cast group. I will also comment in-line below... 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 >>=20 >> 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. >>=20 >> Reviewed by: gnn, bms, bz? >> Obtained from: deischen (with help from) >>=20 >> Modified: >> head/sys/netinet/udp_usrreq.c >>=20 >> Modified: head/sys/netinet/udp_usrreq.c >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- 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 =3D inp->inp_moptions; >> - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && >> - imo !=3D NULL) { >> + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { >> struct sockaddr_in group; >> int blocked; >> - >> + if(imo =3D=3D NULL) { >> + INP_RUNLOCK(inp); >> + continue; >> + } >> bzero(&group, sizeof(struct = sockaddr_in)); >> group.sin_len =3D sizeof(struct = sockaddr_in); >> group.sin_family =3D AF_INET; >=20 > So it turns out that this is a feature, not a bug, and is how = multicast has=20 > always worked. Specifically, if you bind a UDP socket with a wildcard=20= > address, it should receive all traffic for the bound port, unicast or=20= > multicast. When you join a group, you have switched the socket into a = mode=20 > where it now has a whitelist of acceptable multicast groups, but if a = socket=20 > has no joined groups, it should receive all multicast traffic, not = none. This=20 > change breaks that. >=20 > I did not find this behavior intuitive at first, but it does seem to = be=20 > required. Note the description of IP_ADD_MEMBERSHIP from RFC 3678 for=20= > example: I agree getting a packet that is coming to your port without joining the multi-cast group is not intuitive to me...=20 >=20 > 3. Overview of APIs >=20 > 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. >=20 > 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. >=20 > 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: >=20 > + 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. >=20 > + 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. >=20 > 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. Not the above document is talking about a receiver that as joined the multicast group (or is joining it and wants some filtering)... I don't see how that applies to a UDP socket that has NOT joined the M-cast = group.. >=20 >=20 > ..... >=20 > 4.1.1. IPv4 Any-Source Multicast API >=20 > The following socket options are defined in <netinet/in.h> for > applications in the Any-Source Multicast category: >=20 > 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 >=20 > 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. >=20 > 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). >=20 > As to why the packets loop back to the receiver, I believe that is a = separate=20 > issue on the output side, not the receive side. But that is what the commit fixes... and as to the above, it again is talking about Multicast members.. AFAIKT... I am actually at the IETF so if you would like I can gladly go talk to the authors of this RFC (if they are here) and get their opinion on this. One other thing.. note this is NOT a standard but a informational RFC. = Informational RFC are guidelines and NOT mandatory at all.. there will never be a = MUST/SHOULD etc within them. I see that the authors are Dave Thaler, Bill Fenner and B Quinn I don't know B Quinn.. not sure if Fenner is here (have not seen him).. = but I have seen Dave around.. I will look him up and ask him his opinion.. R >=20 > --=20 > John Baldwin >=20 ------------------------------ Randall Stewart 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99FEFE99-455A-4A28-8C02-08DFAD28B6CD>