netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Christoph Lameter <cl@linux.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, nhorman@tuxdriver.com,
	dlstevens@us.ibm.com
Subject: Re: PATCH: Multicast: Filter multicast traffic per socket mc_list
Date: Thu, 16 Apr 2009 11:24:29 -0400	[thread overview]
Message-ID: <49E74DAD.4020507@hp.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0904161035390.19650@qirst.com>

Christoph Lameter wrote:
> Do what David Stevens suggest: Add a per socket option
> 
> 
> 
> Subject: Multicast: Filter Multicast traffic per socket mc_list
> 
> If two processes open the same port as a multicast socket and then
> join two different multicast groups then traffic for both multicast groups
> is forwarded to either process. This means that application will get surprising
> data that they did not ask for. Applications will have to filter these out in
> order to work correctly if multiple apps run on the same system.
> 
> These are pretty strange semantics but they have been around since the
> beginning of multicast support on Unix systems. Most of the other operating
> systems supporting Multicast have since changed to only supplying multicast
> traffic to a socket that was selected through multicast join operations.
> 
> This patch does change Linux to behave in the same way. But there may be
> applications that rely on the old behavior. Therefore we provide a means
> to switch back to the old behavior using a new multicast socket option
> 
> 	IP_MULTICAST_ALL
> 
> If set then all multicast traffic to the port is forwarded to the socket
> (additional constraints are the SSM inclusion and exclusion lists!).
> If not set (default) then only traffic for multicast groups that were
> joined by thesocket is received.
> 
> Signed-off-by: Christoph Lameter <cl@linux.com>
> 
> ---
>  include/linux/in.h      |    1 +
>  include/net/inet_sock.h |    3 ++-
>  net/ipv4/igmp.c         |    4 ++--
>  net/ipv4/ip_sockglue.c  |   11 +++++++++++
>  4 files changed, 16 insertions(+), 3 deletions(-)
> 
> Index: linux-2.6/include/net/inet_sock.h
> ===================================================================
> --- linux-2.6.orig/include/net/inet_sock.h	2009-04-16 08:59:20.000000000 -0500
> +++ linux-2.6/include/net/inet_sock.h	2009-04-16 09:04:47.000000000 -0500
> @@ -130,7 +130,8 @@ struct inet_sock {
>  				freebind:1,
>  				hdrincl:1,
>  				mc_loop:1,
> -				transparent:1;
> +				transparent:1,
> +				mc_all:1;
>  	int			mc_index;
>  	__be32			mc_addr;
>  	struct ip_mc_socklist	*mc_list;
> Index: linux-2.6/net/ipv4/igmp.c
> ===================================================================
> --- linux-2.6.orig/net/ipv4/igmp.c	2009-04-16 08:54:47.000000000 -0500
> +++ linux-2.6/net/ipv4/igmp.c	2009-04-16 09:04:06.000000000 -0500
> @@ -2187,7 +2187,7 @@ int ip_mc_sf_allow(struct sock *sk, __be
>  	struct ip_sf_socklist *psl;
>  	int i;
> 
> -	if (!ipv4_is_multicast(loc_addr))
> +	if (ipv4_is_lbcast(loc_addr) || !ipv4_is_multicast(loc_addr))
>  		return 1;

I don't think this change is needed.  ipv4_is_lbcast() checks if the
address is 255.255.255.255.  That address is already !ipv4_is_multicast().

Subnet broadcasts are also !ipv4_is_multicast.

> 
>  	for (pmc=inet->mc_list; pmc; pmc=pmc->next) {
> @@ -2196,7 +2196,7 @@ int ip_mc_sf_allow(struct sock *sk, __be
>  			break;
>  	}
>  	if (!pmc)
> -		return 1;
> +		return inet->mc_all;
>  	psl = pmc->sflist;
>  	if (!psl)
>  		return pmc->sfmode == MCAST_EXCLUDE;
> Index: linux-2.6/include/linux/in.h
> ===================================================================
> --- linux-2.6.orig/include/linux/in.h	2009-04-16 09:05:41.000000000 -0500
> +++ linux-2.6/include/linux/in.h	2009-04-16 09:32:52.000000000 -0500
> @@ -107,6 +107,7 @@ struct in_addr {
>  #define MCAST_JOIN_SOURCE_GROUP		46
>  #define MCAST_LEAVE_SOURCE_GROUP	47
>  #define MCAST_MSFILTER			48
> +#define IP_MULTICAST_ALL		49
> 
>  #define MCAST_EXCLUDE	0
>  #define MCAST_INCLUDE	1
> Index: linux-2.6/net/ipv4/ip_sockglue.c
> ===================================================================
> --- linux-2.6.orig/net/ipv4/ip_sockglue.c	2009-04-16 09:09:52.000000000 -0500
> +++ linux-2.6/net/ipv4/ip_sockglue.c	2009-04-16 09:31:40.000000000 -0500
> @@ -449,6 +449,7 @@ static int do_ip_setsockopt(struct sock
>  			     (1<<IP_ROUTER_ALERT) | (1<<IP_FREEBIND) |
>  			     (1<<IP_PASSSEC) | (1<<IP_TRANSPARENT))) ||
>  	    optname == IP_MULTICAST_TTL ||
> +	    optname == IP_MULTICAST_ALL ||
>  	    optname == IP_MULTICAST_LOOP ||
>  	    optname == IP_RECVORIGDSTADDR) {
>  		if (optlen >= sizeof(int)) {
> @@ -895,6 +896,13 @@ static int do_ip_setsockopt(struct sock
>  		kfree(gsf);
>  		break;
>  	}
> +	case IP_MULTICAST_ALL:
> +		if (optlen<1)
> +			goto e_inval;
> +		if (val != 0 && val != 1)
> +			goto e_inval;
> +		inet->mc_all = val;
> +		break;
>  	case IP_ROUTER_ALERT:
>  		err = ip_ra_control(sk, val ? 1 : 0, NULL);
>  		break;
> @@ -1147,6 +1155,9 @@ static int do_ip_getsockopt(struct sock
>  		release_sock(sk);
>  		return err;
>  	}
> +	case IP_MULTICAST_ALL:
> +		val = inet->mc_all;
> +		break;
>  	case IP_PKTOPTIONS:
>  	{
>  		struct msghdr msg;

You might need to set inet->mc_all to 1 in inet_create() since I am not sure if
we want to change the default behavior.  The knowledge that some apps have
a very "unique" way of doing multicast makes me a little hesitant.

-vlad

  parent reply	other threads:[~2009-04-16 15:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16 14:38 PATCH: Multicast: Filter multicast traffic per socket mc_list Christoph Lameter
2009-04-16 15:09 ` David Stevens
2009-04-16 15:36   ` Christoph Lameter
2009-04-16 22:15     ` David Miller
2009-04-16 15:15 ` Neil Horman
2009-04-16 15:36   ` Christoph Lameter
2009-04-16 17:44     ` Neil Horman
2009-04-16 19:12       ` Christoph Lameter
2009-04-16 20:56         ` David Stevens
2009-04-16 21:04           ` Christoph Lameter
2009-04-16 21:54             ` David Stevens
2009-04-16 22:19             ` David Miller
2009-04-16 21:19           ` Vlad Yasevich
2009-04-16 22:20             ` David Miller
2009-04-16 22:22             ` David Stevens
2009-04-16 23:30               ` Stephen Hemminger
2009-04-17  0:01               ` Vlad Yasevich
2009-04-16 22:16         ` David Miller
2009-04-17 13:56           ` Christoph Lameter
2009-04-17 15:37             ` Nivedita Singhvi
2009-04-17 16:02               ` Christoph Lameter
2009-04-17 16:28                 ` Nivedita Singhvi
2009-04-17 22:24                 ` David Miller
2009-04-20 18:10                   ` Christoph Lameter
2009-04-17 21:31             ` David Stevens
2009-04-20 16:43               ` Christoph Lameter
2009-04-20 18:46                 ` David Stevens
2009-04-16 15:24 ` Vlad Yasevich [this message]
2009-04-16 15:39   ` 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=49E74DAD.4020507@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).