Thank you for your kindness in helping me. * Robert Elz (k...@munnari.oz.au) wrote: > | Long message does not interest people. :-p > > Often, true, but requiring going to look at an external web page will also > discourage some people... It is a trade off. Personally, I opt external links for long screen dumps.
> | inet6 2405:9800:b550:2939:8638:35ff:fe48:5720/128 flags 0x0 > > which is an extra host address on the same IPv6 subnet as the primary > address, and which has vanished when the ping eventually works. > Second, the route (to myself) for that odd /128 address goes away. Not really, please look below, the screen dump while it is working. The ipv6 address of /128 is still there. And most of the time it is there. And this address is never changed. % ping6 -c 3 -n www.netbsd.org PING6(56=40+8+8 bytes) 2405:9800:b550:2939:f234:69d6:e0bf:8ebf --> 2001:470:a085:999::80 16 bytes from 2001:470:a085:999::80, icmp_seq=0 hlim=51 time=307.804 ms 16 bytes from 2001:470:a085:999::80, icmp_seq=1 hlim=51 time=317.245 ms 16 bytes from 2001:470:a085:999::80, icmp_seq=2 hlim=51 time=244.747 ms --- www.netbsd.org ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 244.747/289.932/317.245/39.415 ms % % ifconfig wm0 wm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx> capabilities=2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx> capabilities=2bf80<UDP6CSUM_Tx> enabled=0 ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU> ec_enabled=0 address: 08:00:27:2b:32:26 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.1.104/24 broadcast 192.168.1.255 flags 0x0 inet6 fe80::bbe5:5eaa:bbaf:950b%wm0/64 flags 0x0 scopeid 0x1 inet6 2405:9800:b550:2939:f234:69d6:e0bf:8ebf/64 flags 0x0 inet6 2405:9800:b550:2939:8638:35ff:fe48:5720/128 flags 0x0 > Oh, I see now that in your original message you said: > Disabling NPF does not fix it. > but it is not clear from than what you meant. Did you test with NPF > disabled from rc.conf and boot that way? Or did you boot, and then > later, when ping6 was not succeeding, turn off NPF ? I tried both disabling NPF after boot and turn it off in /etc/rc.conf. The results are the same. > At this point you are probably going to need help from someone more > familiar with the current NetBSD IPv6 code to figure out what might be > happening, and where to look next. Your kind advices are still highly appreciated. > Oh, somehow I skipped that part. One network is OK, I meant some > other IPv6 host on that same LAN (the point was just to check that > neighbour discovery was working - and I no longer suspect any > issues there, so there is no need to bother with this, even if there > is some other host with a v6 addr that is local that you could ping.) All other machines on the same LAN are working pretty fine. All of them are running dhcp. But this netbsd host I tried both dhcp and static, but it doesn't fix the problem. I shall probably go back and try dhclient. > if it has one (not all routers do) you could try ping6 to the IPv6 > (global) address of the router on theLAN that is connected to > your host. That address would start 2405:9800:b550:2939: > (almost anything might come after that, including :1) Pinging router's IPv6 address works fine. > Oh, how many other hosts are on this LAN? (Regardless of > whether they support v6 or not.) One possibility for the issue > might be if the router thinks the LAN link is down when your > host is down, and drops the announcement of the route from > its upstream (closer to the centre of the net). Then it could > take some time for that to be reannounced after the link > comes back up (when your host boots). IMHO, it is unlikely. I have 8 machines on this LAN. All of them, except this netbsd host, work with IPv6 pretty fine and without any efforts. Thank you, -- Gua Chung Lim "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." -- Dennis M. Ritchie