ipv6: Fix for adding multicast route for loopback device automatically.

PATCH In review Li Wei 2 participants 5 messages Dec 7, 2011 – Dec 13, 2011

Subsystems (3)

Networking Network drivers IPv4/IPv6

lore

Share & tools

lore

Li Wei

author

2011-12-07 07:23 UTC #0 lore raw

PATCH 1/1 ipv6: Fix for adding multicast route for loopback device automatically.

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 <[email protected]>

---
 net/ipv6/addrconf.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

net/ipv6/addrconf.c +2 -1

index cf88df8..36806de 100644
@@ -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);

Signature · 1 line

1.7.3.2

David Miller

maintainer

2011-12-07 20:07 UTC #1 lore raw

From: Li Wei <[email protected]>
Date: Wed, 07 Dec 2011 15:23:45 +0800

Quoted 5 lines

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 <[email protected]>

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?

Li Wei

author

2011-12-08 00:58 UTC #2 lore raw

Quoted 11 lines · David Miller

From: Li Wei <[email protected]>
Date: Wed, 07 Dec 2011 15:23:45 +0800
Quoted 5 lines
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 <[email protected]>
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.

Quoted 5 lines

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

David Miller

maintainer

2011-12-12 23:50 UTC #3 lore raw

From: Li Wei <[email protected]>
Date: Thu, 08 Dec 2011 08:58:21 +0800

Quoted 10 lines

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

Quoted 7 lines

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

Li Wei

author

2011-12-13 00:55 UTC #4 lore raw

Quoted 21 lines

From: Li Wei <[email protected]>
Date: Thu, 08 Dec 2011 08:58:21 +0800
Quoted 10 lines
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
Quoted 7 lines
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.

Quoted 7 lines

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