netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Christoph Lameter <cl@linux.com>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	David Stevens <dlstevens@us.ibm.com>
Subject: Re: [PATCH] Multicast: Avoid useless duplication of multicast	messages
Date: Wed, 15 Apr 2009 13:19:41 -0400	[thread overview]
Message-ID: <49E6172D.8080201@hp.com> (raw)
In-Reply-To: <20090415163812.GD21448@hmsreliant.think-freely.org>

Neil Horman wrote:
find the multicast in the socket's list.
>>
> Also see above, hes using multicast group 239.x.x.x.  SSM only encompases
> addresses in the 232.0.0.1 to 232.255.255.255 range.  He's using ASM not SSM,
> regardless of what SSM allows.  I agree it sounds like we have a bug in SSM
> behavior, but its not overly relevant to this discussion (saving for the fact
> that his new feature would inadvertantly fix the bug, in addition to altering
> ASM behavior).  If we want to fix the SSM bug, thats great, lets fix it, but
> lets not do it by introducing a new behavior to ASM.

Sorry, but I don't buy it.  What we have is essentially "backward-brokeness".

Looking at BSD, which was the root of the original brokeness, they have it fixed.
The code will skip sockets that are not members of a particular group.  So, we
are trying really hard to stay bug-for-bug compatible with old implementations.

> 
> And thats all moot anyway, becaues Christoph (unless I'm mistaken) is not, and
> does not want to restrict source sending privlidges.  He wants to get data on
> multicast groups from all/any source, he just doesn't want to get multicast data
> from groups he didn't explicitly join in the app doing the receiving, which is
> exactly what you can currently use bind for.

Let's look at it the other way.  What is broken if we actually filter based on the
socket group membership?  The only applications that will be impacted are ones that
do not join groups themselves and expect to get multicast traffic.  Such applications
are broken to start with.

We already do group membership check for the socket. We simply incorrectly determine
that any socket that doesn't list a group.

What's worse is that if you have a socket that doesn't care about any mulicast
destinations (never did an ADD_MEMBERSHIP), it will still get multicast traffic if
it bound to that port.

We need to take into account the socket's multicast group list.

-vlad

> 
> Neil
> 
>> -vlad
>>
>>> In particular, if we fail to match the 'datagram's destination address',
>>>> we deliver the packet, which I believe is in violation of the "MUST NOT" above.
>>>>
>>> I think only if the SSM model is used via the socket extensions the RFC
>>> describes.  If Christophs app is subscribing via IP_ADD_SOURCE_MEMBERSHIP, then
>>> yes, we have a problem.  But everything I've read says he uses the standard, any-source
>>> IP_ADD_MEMBERSHIP option which I think makes assertions from RFC 4607 void.
>>> Christoph, are you using IP_ADD_SOURCE_MEMBERSHIP?
>>>
>>> Neil
>>>
>>>> I've CC'd Dave Stevens, since I'd like to hear his opinion regarding this text.
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 


  reply	other threads:[~2009-04-15 17:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-13 21:06 Kernel sends multicast groups to sockets that did not subscribe to the MC group Christoph Lameter
2009-04-14 13:25 ` Neil Horman
2009-04-14 13:53   ` Christoph Lameter
2009-04-14 18:27     ` Neil Horman
2009-04-14 18:33       ` Christoph Lameter
2009-04-14 20:01         ` Neil Horman
2009-04-14 20:16           ` Christoph Lameter
2009-04-14 18:48       ` [PATCH] Multicast: Avoid useless duplication of multicast messages Christoph Lameter
2009-04-14 20:44         ` Neil Horman
2009-04-14 21:45           ` Christoph Lameter
2009-04-15 11:07             ` Neil Horman
2009-04-15 12:51               ` Christoph Lameter
2009-04-15 14:22                 ` Neil Horman
2009-04-15 14:41                   ` Vlad Yasevich
2009-04-15 15:57                     ` Neil Horman
2009-04-15 16:07                       ` Vlad Yasevich
2009-04-15 16:38                         ` Neil Horman
2009-04-15 17:19                           ` Vlad Yasevich [this message]
2009-04-15 17:53                             ` Neil Horman
2009-04-15 19:21                               ` Christoph Lameter
2009-04-15 19:43                                 ` Neil Horman
2009-04-15 19:17                             ` Christoph Lameter
2009-04-15 21:06                               ` Vlad Yasevich
2009-04-15 23:45                                 ` David Miller
2009-04-16 12:44                                   ` Vlad Yasevich
2009-04-15 21:42                     ` David Stevens
2009-04-15 22:16         ` David Stevens
2009-04-16 14:45           ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49E6172D.8080201@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=cl@linux.com \
    --cc=davem@davemloft.net \
    --cc=dlstevens@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).