IPv6 : add multicast routing verify which net_device is lo

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

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

net/ipv6/route.c +16 -3

index b582a0a..3871ef4 100644
@@ -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;
         }
     }

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

From: Gao feng <[email protected]>
Date: Tue, 20 Dec 2011 19:10:24 +0800

Quoted 14 lines

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.

Quoted 1 line

Signed-off-by Wang xingtong <[email protected]>

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