All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont" <rdenis@simphalempin.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Stevens <dlstevens@us.ibm.com>,
	davem@davemloft.net, jmorris@namei.org, kaber@trash.net,
	kuznet@ms2.inr.ac.ru, netdev@vger.kernel.org,
	netdev-owner@vger.kernel.org, pekkas@netcore.fi,
	yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from unjoined groups
Date: Fri, 11 Jul 2008 21:44:44 +0300	[thread overview]
Message-ID: <200807112144.45018.rdenis@simphalempin.com> (raw)
In-Reply-To: <20080711173549.GC4534@hmsreliant.think-freely.org>

Le vendredi 11 juillet 2008 20:35:49 Neil Horman, vous avez écrit :
> So you're saying that if I take a process, call bind, specifying
> INADDR_ANY, and then call setsockopt(...,IP_ADD_MEMBERSHIP,...) specifying
> a multicast group X, that I can expect to recieve messages from other
> multicast addresses that other processes in the system have joined to? 

Yes, he says so. I am not aware of a real standard for the IPv4 socket API: 
POSIX and IETF only defined the IPv6 multicast API, it seems. That being 
noted, the Linux behavior is in accordance with RFC3493:

|     IPV6_JOIN_GROUP
|
|        Join a multicast group on a specified local interface.
|        If the interface index is specified as 0,
|        the kernel chooses the local interface.
|        For example, some kernels look up the multicast group
|        in the normal IPv6 routing table and use the resulting
|        interface.

Note the use of *interface* rather than *socket* here. And then:

|  Note that to receive multicast datagrams a process must join the
|  multicast group to which datagrams will be sent.  UDP applications
|  must also bind the UDP port to which datagrams will be sent.  Some
|  processes also bind the multicast group address to the socket, in
|  addition to the port, to prevent other datagrams destined to that
|  same port from being delivered to the socket.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

      parent reply	other threads:[~2008-07-11 18:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 15:21 [PATCH] IPv4 Multicast: prevent reception of mcast frames from unjoined groups Neil Horman
2008-07-11 16:48 ` Alexey Kuznetsov
2008-07-11 17:31   ` Neil Horman
2008-07-11 17:53     ` David Stevens
2008-07-11 18:23       ` Neil Horman
2008-07-11 19:00         ` David Stevens
2008-07-11 19:27           ` Neil Horman
2008-07-11 17:16 ` David Stevens
2008-07-11 17:35   ` Neil Horman
2008-07-11 18:43     ` David Stevens
2008-07-11 18:44     ` Rémi Denis-Courmont [this message]

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=200807112144.45018.rdenis@simphalempin.com \
    --to=rdenis@simphalempin.com \
    --cc=davem@davemloft.net \
    --cc=dlstevens@us.ibm.com \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=pekkas@netcore.fi \
    --cc=yoshfuji@linux-ipv6.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.