On Sun, 18 Nov 2001, NDSoftware wrote: > > ping6 -I eth0 fe80::2d0:70ff:fe01:811b > > > PING fe80::2d0:70ff:fe01:811b(fe80::2d0:70ff:fe01:811b) from ::1 eth0: > 56 data bytes > 64 bytes from fe80::2d0:70ff:fe01:811b: icmp_seq=1 ttl=64 time=119 usec > 64 bytes from fe80::2d0:70ff:fe01:811b: icmp_seq=2 ttl=64 time=88 usec > 64 bytes from fe80::2d0:70ff:fe01:811b: icmp_seq=3 ttl=64 time=84 usec Ok. > PING fe80::a0:2434:1d91(fe80::a0:2434:1d91) from > fe80::2d0:70ff:fe01:811b eth0: 56 data bytes > >From ::1 icmp_seq=1 Destination unreachable: Address unreachableFrom ::1 > icmp_seq=2 Destination unreachable: Address unreachableFrom ::1 > icmp_seq=3 Destination unreachable: Address unreachableFrom ::1 > icmp_seq=4 Destination unreachable: Address unreachableFrom ::1 > icmp_seq=5 Destination unreachable: Address unreachableFrom ::1 > icmp_seq=6 Destination unreachable: Address unreachable > --- fe80::a0:2434:1d91 ping statistics --- > 8 packets transmitted, 0 received, +6 errors, 100% loss, time 7029ms > > fe80::a0:2434:1d91 is the link adddress of eth2 of the router. > > I understand why with the same configuration Potato ping router and > 6bone but Woody not. It may be the connection between the two is broken. Capture traffic with 'tcpdump -i interface -n ip6' on both ends and see that the messages (ICMP neighbour solications, when you ping6 the other end's link-local address) get through. Another explanation for this is that IPv6 neighbour discovery code is messed up. This can happen if you take down your loopback interface. The problem will not be fixed by merely taking it back up, you have to re-add the addresses on it too. This can lead to e.g. eternal neighbour discovery loops. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
