All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] IPv6 : add multicast routing verify which net_device is lo
@ 2011-12-20  6:13 Wang Xingtong
  2011-12-20  9:47 ` Wang Xingtong
  0 siblings, 1 reply; 6+ messages in thread
From: Wang Xingtong @ 2011-12-20  6:13 UTC (permalink / raw)
  To: netdev; +Cc: davem

In currently routing subsystem, when we lookup a multicast routing
to send muticast packets to outside, rt6_device_match will return
the rt6_info which it's match first. if we add a multicast route on
loopback devices beforce the others interface, rt6_device_match will
retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
we can't send a muticast packet to outside using loopback devices.
It case all multicast packets blocking.

Commit 4af04aba93f47699e disabled kernel add multicast route on lo
automatically. However,  we can't surmise the routing-add order or
interdict add multicast routing on loopback devices in user space.
The bug still exist. So, i think more stronger routing subsystem is
necessary.

Signed-off-by: Wang xingtong <wangxingtong@cn.fujitsu.com>

---
  net/ipv6/route.c |   19 ++++++++++++++++---
  1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b582a0a..3871ef4 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -334,9 +334,16 @@ static inline struct rt6_info 
*rt6_device_match(struct net *net,
      struct rt6_info *local = NULL;
      struct rt6_info *sprt;

-    if (!oif && ipv6_addr_any(saddr))
+    if (!oif && ipv6_addr_any(saddr)){
+        if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
+            ipv6_addr_is_multicast(&rt->rt6i_dst.addr))){
+            rt=rt->dst.rt6_next;
+            goto match;
+        }
          goto out;
+    }

+match:
      for (sprt = rt; sprt; sprt = sprt->dst.rt6_next) {
          struct net_device *dev = sprt->rt6i_dev;

@@ -355,9 +362,15 @@ static inline struct rt6_info 
*rt6_device_match(struct net *net,
                  local = sprt;
              }
          } else {
-            if (ipv6_chk_addr(net, saddr, dev,
-                      flags & RT6_LOOKUP_F_IFACE))
+            if (ipv6_addr_any(saddr)){
+                if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
+                    ipv6_addr_is_multicast(&rt->rt6i_dst.addr))){
+                    continue;
                  return sprt;
+            }
+            else if (ipv6_chk_addr(net, saddr, dev,
+                      flags & RT6_LOOKUP_F_IFACE))
+                    return sprt;
          }
      }

-- 
1.7.1

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

* Re: [PATCH] IPv6 : add multicast routing verify which net_device is lo
  2011-12-20  6:13 [PATCH] IPv6 : add multicast routing verify which net_device is lo Wang Xingtong
@ 2011-12-20  9:47 ` Wang Xingtong
  2011-12-20 11:10   ` [PATCH V2] " Gao feng
  0 siblings, 1 reply; 6+ messages in thread
From: Wang Xingtong @ 2011-12-20  9:47 UTC (permalink / raw)
  To: netdev; +Cc: davem

Wang Xingtong 写道:
> In currently routing subsystem, when we lookup a multicast routing
> to send muticast packets to outside, rt6_device_match will return
> the rt6_info which it's match first. if we add a multicast route on
> loopback devices beforce the others interface, rt6_device_match will
> retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
> we can't send a muticast packet to outside using loopback devices.
> It case all multicast packets blocking.
> 
> Commit 4af04aba93f47699e disabled kernel add multicast route on lo
> automatically. However,  we can't surmise the routing-add order or
> interdict add multicast routing on loopback devices in user space.
> The bug still exist. So, i think more stronger routing subsystem is
> necessary.

sorry, the patch has some problem , i will send V2 later.

> 
> Signed-off-by: Wang xingtong <wangxingtong@cn.fujitsu.com>
> 
> ---
>  net/ipv6/route.c |   19 ++++++++++++++++---
>  1 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index b582a0a..3871ef4 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -334,9 +334,16 @@ static inline struct rt6_info 
> *rt6_device_match(struct net *net,
>      struct rt6_info *local = NULL;
>      struct rt6_info *sprt;
> 
> -    if (!oif && ipv6_addr_any(saddr))
> +    if (!oif && ipv6_addr_any(saddr)){
> +        if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
> +            ipv6_addr_is_multicast(&rt->rt6i_dst.addr))){
> +            rt=rt->dst.rt6_next;
> +            goto match;
> +        }
>          goto out;
> +    }
> 
> +match:
>      for (sprt = rt; sprt; sprt = sprt->dst.rt6_next) {
>          struct net_device *dev = sprt->rt6i_dev;
> 
> @@ -355,9 +362,15 @@ static inline struct rt6_info 
> *rt6_device_match(struct net *net,
>                  local = sprt;
>              }
>          } else {
> -            if (ipv6_chk_addr(net, saddr, dev,
> -                      flags & RT6_LOOKUP_F_IFACE))
> +            if (ipv6_addr_any(saddr)){
> +                if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
> +                    ipv6_addr_is_multicast(&rt->rt6i_dst.addr))){
> +                    continue;
>                  return sprt;
> +            }
> +            else if (ipv6_chk_addr(net, saddr, dev,
> +                      flags & RT6_LOOKUP_F_IFACE))
> +                    return sprt;
>          }
>      }
> 

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

* [PATCH V2] IPv6 : add multicast routing verify which net_device is lo
  2011-12-20  9:47 ` Wang Xingtong
@ 2011-12-20 11:10   ` Gao feng
  2011-12-21  6:15     ` David Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Gao feng @ 2011-12-20 11:10 UTC (permalink / raw)
  To: netdev; +Cc: davem, Wang xingtong

In currently routing subsystem, when we lookup a multicast routing
to send muticast packets to outside, rt6_device_match will return
the rt6_info which it's match first. If we add a multicast route on
loopback devices beforce the others interface, rt6_device_match will
retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
we can't send a muticast packet to outside using loopback devices.
It case all multicast packets blocking.

Commit 4af04aba93f47699e disabled kernel add multicast route on lo
automatically. However,  we can't surmise the routing-add order or
interdict add multicast routing on loopback devices in user space.
The bug still exist. So, i think, more stronger routing subsystem is
necessary.

Signed-off-by: Wang xingtong <wangxingtong@cn.fujitsu.com>
---
 net/ipv6/route.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b582a0a..d6663ca 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -334,9 +334,16 @@ static inline struct rt6_info *rt6_device_match(struct net *net,
 	struct rt6_info *local = NULL;
 	struct rt6_info *sprt;
 
-	if (!oif && ipv6_addr_any(saddr))
+	if (!oif && ipv6_addr_any(saddr)){
+		if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
+			ipv6_addr_is_multicast(&rt->rt6i_dst.addr))){
+			rt=rt->dst.rt6_next;
+			goto match;
+		}
 		goto out;
+	}
 
+match:
 	for (sprt = rt; sprt; sprt = sprt->dst.rt6_next) {
 		struct net_device *dev = sprt->rt6i_dev;
 
@@ -355,9 +362,15 @@ static inline struct rt6_info *rt6_device_match(struct net *net,
 				local = sprt;
 			}
 		} else {
-			if (ipv6_chk_addr(net, saddr, dev,
-					  flags & RT6_LOOKUP_F_IFACE))
+			if (ipv6_addr_any(saddr)){
+				if (unlikely(rt->rt6i_dev->flags & IFF_LOOPBACK &&
+					ipv6_addr_is_multicast(&rt->rt6i_dst.addr)))
+					continue;
 				return sprt;
+			}
+			else if (ipv6_chk_addr(net, saddr, dev,
+					  flags & RT6_LOOKUP_F_IFACE))
+					return sprt;
 		}
 	}
 
-- 
1.7.1

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

* Re: [PATCH V2] IPv6 : add multicast routing verify which net_device is lo
  2011-12-20 11:10   ` [PATCH V2] " Gao feng
@ 2011-12-21  6:15     ` David Miller
  2011-12-21  9:01       ` Wang Xingtong
  0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2011-12-21  6:15 UTC (permalink / raw)
  To: gaofeng; +Cc: netdev, wangxingtong

From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 20 Dec 2011 19:10:24 +0800

> In currently routing subsystem, when we lookup a multicast routing
> to send muticast packets to outside, rt6_device_match will return
> the rt6_info which it's match first. If we add a multicast route on
> loopback devices beforce the others interface, rt6_device_match will
> retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
> we can't send a muticast packet to outside using loopback devices.
> It case all multicast packets blocking.
> 
> Commit 4af04aba93f47699e disabled kernel add multicast route on lo
> automatically. However,  we can't surmise the routing-add order or
> interdict add multicast routing on loopback devices in user space.
> The bug still exist. So, i think, more stronger routing subsystem is
> necessary.
> 
> Signed-off-by: Wang xingtong <wangxingtong@cn.fujitsu.com>

Ok, this is getting rediculious.  I want to revert all of this
stuff.

How about, instead, we stop userland adding explicit addresses to the
loopback device since that's what started behaving differently
recently and causes these problems in the first place?

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

* Re: [PATCH V2] IPv6 : add multicast routing verify which net_device is lo
  2011-12-21  6:15     ` David Miller
@ 2011-12-21  9:01       ` Wang Xingtong
  2011-12-21 19:11         ` David Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Wang Xingtong @ 2011-12-21  9:01 UTC (permalink / raw)
  To: David Miller; +Cc: gaofeng, netdev


> From: Gao feng <gaofeng@cn.fujitsu.com>
> Date: Tue, 20 Dec 2011 19:10:24 +0800
> 
>> In currently routing subsystem, when we lookup a multicast routing
>> to send muticast packets to outside, rt6_device_match will return
>> the rt6_info which it's match first. If we add a multicast route on
>> loopback devices beforce the others interface, rt6_device_match will
>> retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
>> we can't send a muticast packet to outside using loopback devices.
>> It case all multicast packets blocking.
>>
>> Commit 4af04aba93f47699e disabled kernel add multicast route on lo
>> automatically. However,  we can't surmise the routing-add order or
>> interdict add multicast routing on loopback devices in user space.
>> The bug still exist. So, i think, more stronger routing subsystem is
>> necessary.
>>
>> Signed-off-by: Wang xingtong <wangxingtong@cn.fujitsu.com>
> 
> Ok, this is getting rediculious.  I want to revert all of this
> stuff.
> 
> How about, instead, we stop userland adding explicit addresses to the
> loopback device since that's what started behaving differently
> recently and causes these problems in the first place?

OK, David, I reproduce this as following :

1) ip -6 route show | grep ff00
    unreachable ff00::/8 dev lo  metric 1024  error -101
    ff00::/8 dev eth1  metric 1024

2) ip -6 route del ff00::/8 dev eth1
    ip -6 route del ff00::/8 dev lo

3) ip -6 route add ff00::/8 dev lo
    ip -6 route add ff00::/8 dev eth1

now, if we join to the multicast group with the interface index is 
specified as 0, not restrict devices( oif == 0 ), not restrict saddr ( 
saddr == :: ), rt6_device_match  will return rt6_info which 
rt6i_dev->name is "lo" all the while, and rt6i_dev->error is
"-ENETUNREACH".  we got "ENODEV" at userspace,  all multicast packets 
will be blocked .

But, in fact, eth1 can be uesd and we missed. This is a bug in routing 
system, isn't it?

This patch add multicast routing check-up in rt6_device_match to arrest
it return loopback device when we isn't specified interface and saddr.

thanks,

wang xingtong

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

* Re: [PATCH V2] IPv6 : add multicast routing verify which net_device is lo
  2011-12-21  9:01       ` Wang Xingtong
@ 2011-12-21 19:11         ` David Miller
  0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2011-12-21 19:11 UTC (permalink / raw)
  To: wangxingtong; +Cc: gaofeng, netdev

From: Wang Xingtong <wangxingtong@cn.fujitsu.com>
Date: Wed, 21 Dec 2011 17:01:21 +0800

> OK, David, I reproduce this as following :
> 
> 1) ip -6 route show | grep ff00
>    unreachable ff00::/8 dev lo  metric 1024  error -101
>    ff00::/8 dev eth1  metric 1024
> 
> 2) ip -6 route del ff00::/8 dev eth1
>    ip -6 route del ff00::/8 dev lo
> 
> 3) ip -6 route add ff00::/8 dev lo
>    ip -6 route add ff00::/8 dev eth1

My answer is "Don't ever do that."  The kernel sets up the
loopback device with all the necessary parameters you need
including the address, network prefix, and (once we revert
the recent bogus ipv6 autoconf patch) the multicast prefix.

There is no reason to ever explicit set the things that the
kernel takes care of for you.

That was exactly my point, the piece of userspace that has
started doing this needs to be fixed and we need to revert
Li Wei's recent patch.

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

end of thread, other threads:[~2011-12-21 19:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20  6:13 [PATCH] IPv6 : add multicast routing verify which net_device is lo Wang Xingtong
2011-12-20  9:47 ` Wang Xingtong
2011-12-20 11:10   ` [PATCH V2] " Gao feng
2011-12-21  6:15     ` David Miller
2011-12-21  9:01       ` Wang Xingtong
2011-12-21 19:11         ` David Miller

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.