Date: Sat, 28 Jul 2018 22:04:58 +0700
From: Gua Chung Lim <gua.chung...@gmail.com>
Message-ID: <20180728150458.ga1...@gmail.com>
| > ping6 fe80::1%wm0
| It still works pretty fine.
In general when using LL addresses, especially on a host with multiple
interfaces, you should always specify which interface (the address "scope")
as the same LL address can exist on multiple different interfaces (and
also otherwise ping6, or the kernel, has to guess which interterface you
mean.)
| I show you both ping6 and ping...
OK, the ping6 result to the netbsd address at least is just hanging,
not returning an error, which indicates packet loss, (of some form).
| I always avoid long message.
A good general principle, yes...
| 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.
| The message at the bottom usually gets hidden and left unread by people.
Then you put the important stuff first, and at the end the random extra data
(like routing tables) that only someone who really wants to understand need
bother with. Of course, assuming that there isn't *too* much (ia dump of the
routing tables from something with the complete core internet routes would be
a bit much!)
| # ifconfig -a
The one odd thing in this is:
| 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 primaty
address, and which has vanished when the ping eventually works.
And in the second ifconfig (after things work), a new interface has
appeared...
| npflog0: flags=0x1<UP>
which I suspect means that you have npf configured for filtering (but
it was not there when the ping was failing).
Can I ask that you disable all (local) filtering on the host until this issue
is solved, if things just work when npf is not used at all, then we know
where to look next.
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 ?
The routing tables show just a couple of differences, first the wm0 IPv6 local
net route (to 2405:9800:b550:2939::/64) changes its MTU from 1500 (standard
ethernet default) to 1990, I am not sure what is going on there, but a bigger
MTU should have no effect on a ping packet (which is small, especially the
IPv6 pings which aren't padded with counting bytes by default).
Second, the route (to myself) for that odd /128 address goes away.
(And third, and should be irrelevant, an NBP entry, showing the MAC addr of
some other host on the wm0 lan also goes away - those time out if not
continually used, so this is not a surprise.)
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.
kre
