netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
@ 2011-12-07  7:23 Li Wei
  2011-12-07 20:06 ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Li Wei @ 2011-12-07  7:23 UTC (permalink / raw)
  To: netdev; +Cc: David S. Miller, yoshfuji

There is no obvious reason to add a default multicast route for loopback
devices, otherwise there would be a route entry whose dst.error set to
-ENETUNREACH that would blocking all multicast packets.

Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
 net/ipv6/addrconf.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cf88df8..36806de 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1805,7 +1805,8 @@ static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
 		return ERR_PTR(-EACCES);
 
 	/* Add default multicast route */
-	addrconf_add_mroute(dev);
+	if (!(dev->flags & IFF_LOOPBACK))
+		addrconf_add_mroute(dev);
 
 	/* Add link local route */
 	addrconf_add_lroute(dev);
-- 
1.7.3.2

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
  2011-12-07  7:23 [PATCH] ipv6: Fix for adding multicast route for loopback device automatically Li Wei
@ 2011-12-07 20:06 ` David Miller
  2011-12-08  0:58   ` Li Wei
  0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2011-12-07 20:06 UTC (permalink / raw)
  To: lw; +Cc: netdev, yoshfuji

From: Li Wei <lw@cn.fujitsu.com>
Date: Wed, 07 Dec 2011 15:23:45 +0800

> There is no obvious reason to add a default multicast route for loopback
> devices, otherwise there would be a route entry whose dst.error set to
> -ENETUNREACH that would blocking all multicast packets.
> 
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>

I still do not understand the purpose of this change, what problems
does the current behavior cause?

And can you be sure that by making this change, you are not breaking
something, somewhere, that depends upon the current behavior?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
  2011-12-07 20:06 ` David Miller
@ 2011-12-08  0:58   ` Li Wei
  2011-12-12 23:49     ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Li Wei @ 2011-12-08  0:58 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, yoshfuji

David Miller wrote:
> From: Li Wei <lw@cn.fujitsu.com>
> Date: Wed, 07 Dec 2011 15:23:45 +0800
> 
>> There is no obvious reason to add a default multicast route for loopback
>> devices, otherwise there would be a route entry whose dst.error set to
>> -ENETUNREACH that would blocking all multicast packets.
>>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
> 
> I still do not understand the purpose of this change, what problems
> does the current behavior cause?

Hi, David, thank you for your comment.

The problem is that the resulting routing table depends on the sequence
of interface's initialization and in some situation, that would block all
muticast packets. Suppose there are two interfaces on my computer
(lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
table(for multicast) would be

# ip -6 route show | grep ff00::
unreachable ff00::/8 dev lo metric 256 error -101
ff00::/8 dev eth0 metric 256

When sending multicasting packets, routing subsystem will return the first
route entry which with a error set to -101(ENETUNREACH).

I know the kernel will set the default ipv6 address for 'lo' when it is up
and won't set the default multicast route for it, but there is no reason to
stop 'init' program from setting address for 'lo', and that is exactly what
systemd did.

I am sure there is something wrong with kernel or systemd, currently I preferred
kernel caused this problem.

> 
> And can you be sure that by making this change, you are not breaking
> something, somewhere, that depends upon the current behavior?
> 
> 

I can't see there is any reason to set a default multicast route for loopback device
*automatically*. 

Thanks, 
Wei

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
  2011-12-08  0:58   ` Li Wei
@ 2011-12-12 23:49     ` David Miller
  2011-12-13  0:56       ` Li Wei
  0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2011-12-12 23:49 UTC (permalink / raw)
  To: lw; +Cc: netdev, yoshfuji

From: Li Wei <lw@cn.fujitsu.com>
Date: Thu, 08 Dec 2011 08:58:21 +0800

> The problem is that the resulting routing table depends on the sequence
> of interface's initialization and in some situation, that would block all
> muticast packets. Suppose there are two interfaces on my computer
> (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
> table(for multicast) would be
> 
> # ip -6 route show | grep ff00::
> unreachable ff00::/8 dev lo metric 256 error -101
> ff00::/8 dev eth0 metric 256
> 
> When sending multicasting packets, routing subsystem will return the first
> route entry which with a error set to -101(ENETUNREACH).
> 
> I know the kernel will set the default ipv6 address for 'lo' when it is up
> and won't set the default multicast route for it, but there is no reason to
> stop 'init' program from setting address for 'lo', and that is exactly what
> systemd did.

Ok, I added this more detailed explanation to the commit message and
applied your patch.

Probably it is a good idea to explain things completely, with all details
and examples, in the commit message from the beginning :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
  2011-12-12 23:49     ` David Miller
@ 2011-12-13  0:56       ` Li Wei
  0 siblings, 0 replies; 5+ messages in thread
From: Li Wei @ 2011-12-13  0:56 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, yoshfuji

> From: Li Wei <lw@cn.fujitsu.com>
> Date: Thu, 08 Dec 2011 08:58:21 +0800
> 
>> The problem is that the resulting routing table depends on the sequence
>> of interface's initialization and in some situation, that would block all
>> muticast packets. Suppose there are two interfaces on my computer
>> (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
>> table(for multicast) would be
>>
>> # ip -6 route show | grep ff00::
>> unreachable ff00::/8 dev lo metric 256 error -101
>> ff00::/8 dev eth0 metric 256
>>
>> When sending multicasting packets, routing subsystem will return the first
>> route entry which with a error set to -101(ENETUNREACH).
>>
>> I know the kernel will set the default ipv6 address for 'lo' when it is up
>> and won't set the default multicast route for it, but there is no reason to
>> stop 'init' program from setting address for 'lo', and that is exactly what
>> systemd did.
> 
> Ok, I added this more detailed explanation to the commit message and
> applied your patch.
> 
> Probably it is a good idea to explain things completely, with all details
> and examples, in the commit message from the beginning :-)
> 
> 

Thanks David, remember your advice :)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-12-13  0:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-07  7:23 [PATCH] ipv6: Fix for adding multicast route for loopback device automatically Li Wei
2011-12-07 20:06 ` David Miller
2011-12-08  0:58   ` Li Wei
2011-12-12 23:49     ` David Miller
2011-12-13  0:56       ` Li Wei

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).