Hi Martin,
On Fri, Nov 04, 2016 at 11:44:14AM +0100, Martin Pieuchot wrote:
>
> That's the problem. The entry is flagged as RTF_LLINFO but contains an
> IPv6 address.
>
> Do you see any other errors in /log/messages?
>
Only
nd6_rtrequest: bad gateway value: tap0
immediately before the printf gets triggered. I tried reproducing the
problem in a cleaner environment, since the one I'm seeing this in is a
bit convoluted.
tap0 is usually managed by tinc. Immediately after starting it,
everything looks fine:
$ route -n show -inet6 | grep tap0
2001:470:74bb::/64 2001:470:74bb::1 UCn 0
0 - 4 tap0
2001:470:74bb::1 fe:e1:ba:d4:0f:e3 UHLl 0
0 - 1 tap0
fd97:1c82:9447::/64 fd97:1c82:9447::1 UCn 0
0 - 4 tap0
fd97:1c82:9447::1 fe:e1:ba:d4:0f:e3 UHLl 0
0 - 1 tap0
fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0 UCn 0
0 - 4 tap0
fe80::fce1:baff:fed4:fe3%tap0 fe:e1:ba:d4:0f:e3 UHLl 0
0 - 1 tap0
ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0 2
- 4 tap0
ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0 2
- 4 tap0
$ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d4:0f:e3
index 14 priority 15 llprio 3
groups: tap tinc unobtanium
status: active
inet 172.22.127.2 netmask 0xffffff00 broadcast 172.22.127.255
inet6 fe80::fce1:baff:fed4:fe3%tap0 prefixlen 64 scopeid 0xe
inet6 2001:470:74bb::1 prefixlen 64 deprecated pltime 0 vltime infty
inet6 fd97:1c82:9447::1 prefixlen 64 deprecated pltime 0 vltime infty
Pinging across the tunnel (the other side has fd97:1c82:9447:: as one of
its addresses on the tunnel) doesn't work:
$ ping6 -n -c1 fd97:1c82:9447::
PING fd97:1c82:9447:: (fd97:1c82:9447::): 56 data bytes
--- fd97:1c82:9447:: ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
and causes the 'bad gateway value' message to appear, followed by a few
'something odd happens'. Now the routing table looks like this:
$ route -n show -inet6 | grep tap0
2001:470:74bb::/64 2001:470:74bb::1 UCn 0
0 - 4 tap0
2001:470:74bb::1 fe:e1:ba:d4:0f:e3 UHLl 0
0 - 1 tap0
fd97:1c82:9447::/64 fd97:1c82:9447::1 UCn 1
0 - 4 tap0
fd97:1c82:9447:: fe:e1:ba:d0:26:57 UHLc 1
2 - 4 tap0
^^^^^^^^^^^^^^^^^
fd97:1c82:9447::1 fe:e1:ba:d4:0f:e3 UHLl 0
0 - 1 tap0
fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0 UCn 1
3 - 4 tap0
fe80::fce1:baff:fed0:2657%tap0 fe:e1:ba:d0:26:57 UHLc 0
10 - 4 tap0
fe80::fce1:baff:fed4:fe3%tap0 fe:e1:ba:d4:0f:e3 UHLl 0
3 - 1 tap0
ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0
2 - 4 tap0
ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0
3 - 4 tap0
This is what shows up on tap0 when I do the ping6:
$ doas tcpdump -ni tap0 ip6
tcpdump: listening on tap0, link-type EN10MB
19:23:45.315411 fe80::fce1:baff:fed9:9d3f > ff02::1:ff00:0: icmp6: neighbor
sol: who has fd97:1c82:9447::
19:23:45.373281 fe80::fce1:baff:fed0:2657 > fe80::fce1:baff:fed9:9d3f: icmp6:
neighbor adv: tgt is fd97:1c82:9447::
19:23:45.373477 fd00::82fa:5bff:fe33:76b3 > fd97:1c82:9447::: icmp6: echo
request
I can't reproduce the problem when I configure a tap device similar to
how tinc does it and use `cat /dev/tap0 >/dev/null` to keep the device
open, which leads me to assume that the neighbour advertisement received
from fe80::fce1:baff:fed9:9d3f leads to this weird new route.
If I can do anything else to be of assistance, please let me know.
--
Gregor
