svn commit: r217592 - head/sys/netinet
Randall Stewart
rrs at lakerest.net
Wed Mar 30 11:27:43 UTC 2011
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
>>
>> 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:
I agree getting a packet that is coming to your port without joining the
multi-cast group is not intuitive to me...
>
> 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.
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..
>
>
> .....
>
> 4.1.1. IPv4 Any-Source Multicast API
>
> The following socket options are defined in <netinet/in.h> 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.
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
>
> --
> John Baldwin
>
------------------------------
Randall Stewart
803-317-4952 (cell)
More information about the svn-src-all
mailing list