diff mbox

IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets?

Message ID 4BCFA615.8060205@hp.com
State Rejected, archived
Delegated to: David Miller
Headers show

Commit Message

Brian Haley April 22, 2010, 1:27 a.m. UTC 
Sam Cannell wrote:
> I've been having some trouble with ip6 duplicate address detection in a
> Linux VM (under XVM on OpenSolaris).  It seems that the ethernet bridge
> in XVM sends a host's own multicast packets back to it, which the
> duplicate address detection code in linux decide that another host on
> the network is using the same address.
<snip>
>
> I'd happily put this down to a failing in XVM, however the stateless
> autoconfiguration RFC (4862) states that the stack shouldn't decide an
> address is duplicate based on receipt of a neighbor solicitation message
> that it sent itself:
<snip>
> 
> Assuming my understanding of the RFC is correct, this suggests to me
> that duplicate address detection in Linux is being a little too hasty to
> mark the address as invalid.  Thoughts?

Well, my initial reaction is XVM is doing the wrong thing looping-back
multicast packets.  You can try the following (untested) patch, I can
only confirm it compiles.

-Brian


Add a check for looped-back DAD packets on Ethernet interfaces.

Signed-off-by: Brian Haley <brian.haley@hp.com>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Herbert Xu April 22, 2010, 2:41 a.m. UTC | #1 
Brian Haley <brian.haley@hp.com> wrote:
> 
> Well, my initial reaction is XVM is doing the wrong thing looping-back
> multicast packets.  You can try the following (untested) patch, I can
> only confirm it compiles.

I agree, whatever is looping the packet back should be fixed.

And if we are going to filter them out at our end, then it should
be done below IP.

Thanks,
David Miller April 22, 2010, 5:30 a.m. UTC | #2 
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Apr 2010 10:41:40 +0800

> Brian Haley <brian.haley@hp.com> wrote:
>> 
>> Well, my initial reaction is XVM is doing the wrong thing looping-back
>> multicast packets.  You can try the following (untested) patch, I can
>> only confirm it compiles.
> 
> I agree, whatever is looping the packet back should be fixed.

Ethernet does not send multicasts to itself, so we're definitely not
going to cater to this XVM behavior.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index da0a4d2..33a7212 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -57,6 +57,7 @@ 
 #include <linux/net.h>
 #include <linux/in6.h>
 #include <linux/route.h>
+#include <linux/etherdevice.h>
 #include <linux/init.h>
 #include <linux/rcupdate.h>
 #include <linux/slab.h>
@@ -800,6 +801,16 @@  static void ndisc_recv_ns(struct sk_buff *skb)
 					}
 				}
 
+				if (dev->type == ARPHRD_ETHER) {
+					struct ethhdr *eth = eth_hdr(skb);
+					if (!compare_ether_addr_64bits(
+								dev->dev_addr,
+								eth->h_source)){
+						/* looped-back to us */
+						goto out;
+					}
+				}
+
 				/*
 				 * We are colliding with another node
 				 * who is doing DAD