Date: Sun, 29 Jul 2018 23:05:01 +0700
From: Gua Chung Lim <gua.chung...@gmail.com>
Message-ID: <20180729160500.ga3...@gmail.com>
| I don't suspect my router,
| I don't suspect dhcpcd
| I don't suspect name resolution
|
| Any ideas?
First, stop not suspecting ... that is jumping to conclusions, and until there
is some actual evidence, that is the way to completely fail to find the
problem.
Of those, only the DNS looks to be unrelated (as things fail when it is not
used at all).
Given that all that changed between working and not working my current
guess is that it might be a combination of the other two interacting.
But once again, this is just a guess, and may be no more useful than
the last guess of mine turned out to be.
IIt appears that your router is configured to send RAs that instruct the
host to both attoconfigure an address, and to obtain an address via DHCP.
NetBSD 7 would have ignored the DHCP part, as there was no DHCPv6
client there, and the host would have just autoconfigured an address and
used it. It is not impossible that the other hosts on your LAN are either
doing that, or are obtaining an address from DHCP and not bothering with
autoconf, and that might be the difference between things working and not.
Is the DHCP server in the router?
If so, one possibility is that when it assigns an address to a client host, it
expects the client to use that address, and not something else. Your NetBSD-8
host is using its autoconfigured address, and ignoring (though configuring)
the DHCP assigned one. The router might be dropping packets either from,
or to, the autoconfigured address.
You need to examine the network and see what packets are being sent and
received. Since I'm guessing you have a switched LAN (if not you could
use one of the other hosts to do this, and that would give better results - and
almost all OSs can monitor the network, so it shouldn't matter which the other
host is running) - but back to the switched net, on the netbsd host you can
run tcpdump save the packets, and then tcpdump or wireshark to analyse
them (obviously wireshark can capture as well, but to just save packets to a
file, tcpdump is easier to use).
Something like
tcpdump -s 2000 -w DUMP-FILE -i wm0
and run that while ping6 is not working, and then while tcpdump is running
attempt a new ping6 (iuse a global literal IPv6 address, just to avoid DNS
query/reply packets cluttering the dump).
After the ping6 has failed, you can kill the tcpdump (which will have saved
everything visible to this host when invked that way.)
Then (after killing that tcpdump - if running in foreground, just ^C to
interrupt it, if in background, just "kill pid" - not kill -9) use tcpdump
again to view the packets
tcpdump -s 2000 -r DUMP-FILE
and if that produces too much output you can add more to that command
line to filter the results). Doing it this way (save to a file, then read the
file) lets you do the "tcpdump -r" over and over again, using the same packets
from the file, with different options (you might eventually need to add -v
for example). You can also use wireshark if you prefer that,a nd just
tell it to read packets from DUMP-FILE. Obviously you can use whatever
file name you like (eg: /tmp/wm0.dump) instead of DUMP-FILE ...
If there's any way to do it, finding out what is being sent out of the internet
side of the router would help as well - is it forwarding the packets from
yor host towards www.netbsd.org (or whatever host you are v6 pinging).
If we can sync on a time to do it (which might not be easy) you could
ping6 -n 2001:3c8:9007:1::21 (munnari.oz.au - one of its addresses) and I
could watch here and see if your packets are arriving or not (but for that
to be practical I need to know exactly when the ping will happen, to at
least the correct minute, and I need to be available, and remember....)
I could also try a ping6 from here to your host if I know more or less
exactly what time to do it (when your host has just rebooted and things
are not working as they should).
If your packets are leaving your host, going to the MAC addr of the router,
and are being sent out of the router, then we can assume that replies are
being sent, and should be getting back to your router, then we need to
know if those packets are being sent from your router back towards your
host. And if they are, if they are arriving and being dropped, or not
arriving at all.
You can also look at "netstat -s" output, before, during, and after, a ping6
that is failing, and see which numbers are growing - and let us know
(save the output in a file - a new one each time, then diff the files to
see what changed - then you might need to look back in the files to
match up the diff outpuyt with the actual block of numbers, to make sure
that it is correctly interpreted, just knowiung "N bad checksums" with
N growing over time is not useful if we don't know if that line refers to
IPv4 ICMP or IPv6 ICMP (for example).
In any case, there is lots more that can be done. And perhaps Roy
can suggest some options for dhcpcd which would make it ignore the
"use DHCP" in the RA or ignore the "autoconfigure using this prefix"
so you could try each of those (if it can be done) and see if one helps.
kre
