All of lore.kernel.org
 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 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.