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

Previous thread: REFNO.:BMW/74-A0802742010 by BMW CUSTOMER SERVICE on Tuesday, April 20, 2010 - 5:47 pm. (1 message)

Next thread: [PATCH] acecad: fix incorrect size parameter in usb_buffer_free by Axel Lin on Tuesday, April 20, 2010 - 6:07 pm. (2 messages)

Hi,

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.

For instance, running:

router4:~ # ip addr add fe80::216:36ff:fe4e:461c/64 dev eth0


I get the following output in tcpdump:

router4:~ # tcpdump -nevpi eth0 ip6 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
12:33:03.755897 00:16:36:4e:46:1c > 33:33:00:00:00:16, ethertype IPv6
(0x86dd), length 90: (hlim 1, next-header Options (0) payload length:
36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6,
multicast listener report v2, length 28, 1 group record(s) [gaddr
ff02::1:ff4e:461c to_ex, 0 source(s)]
12:33:04.551772 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
12:33:04.551998 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel


And dmesg says:

router4:~ # dmesg
[  371.024287] eth0: IPv6 duplicate address fe80::216:36ff:fe4e:461c
detected!


And the address sits in 'tentative' mode:

router4:~ # ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:16:36:4e:46:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
    inet6 fe80::216:36ff:fe4e:461c/64 scope link tentative flags 08 
       valid_lft forever preferred_lft ...

Sorry, just realised I forgot to note that this behaviour occurs in
2.6.33.


Previous thread: REFNO.:BMW/74-A0802742010 by BMW CUSTOMER SERVICE on Tuesday, April 20, 2010 - 5:47 pm. (1 message)

Next thread: [PATCH] acecad: fix incorrect size parameter in usb_buffer_free by Axel Lin on Tuesday, April 20, 2010 - 6:07 pm. (2 messages)