Hi,
today I observed something that I can't explain, and maybe one of you has
an idea.
I'm working on OpenVPN's IPv6 support, and today I tried "tap(4)" mode
on NetBSD 5.1_STABLE (on Sparc64, if that's relevant).
OpenVPN configures the tap0 interface just fine:
/sbin/ifconfig tap0 inet6 2001:608:4:a053::1:0/64
/sbin/route add -inet6 2001:608:4:a053::/64 2001:608:4:a053::1:0
and this is how the results look like:
$ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: f2:0b:a4:00:49:22
media: Ethernet autoselect
inet 10.100.53.2 netmask 0xffffff00 broadcast 10.100.53.255
inet6 fe80::f00b:a4ff:fe00:4922%tap0 prefixlen 64 scopeid 0x9
inet6 2001:608:4:a053::1:0 prefixlen 64
$ netstat -rn |grep tap
10.100/16 10.100.53.1 UGS 0 0 - tap0
10.100.53/24 link#9 UC 1 0 - tap0
10.100.53.1 link#9 UHLc 1 0 - tap0
2001:608:4:a000::/56 2001:608:4:a053::1 UGS 0
0 - tap0
2001:608:4:a053::/64 2001:608:4:a053::1:0 UGS 1
0 - tap0
fe80::%tap0/64 link#9 UC 0 0
- tap0
fe80::f00b:a4ff:fe00:4922%tap0 f2:0b:a4:00:49:22 UHL 0 0
- lo0
ff01:9::/32 link#9 UC 0 0
- tap0
ff02::%tap0/32 link#9 UC 0 0
- tap0
Now I go and ping the OpenVPN server:
$ ping6 2001:608:4:a053::1
PING6(56=40+8+8 bytes) 2001:608:4:a053::1:0 --> 2001:608:4:a053::1
ping6: sendmsg: No route to host
ping6: wrote 2001:608:4:a053::1 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:608:4:a053::1 16 chars, ret=-1
^C
--- 2001:608:4:a053::1 ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
... which doesn't work.
Doing a parallel tcpdump on the tap0 shows "no activity"(!), "ndp -a"
shows no hint about 2001:608:4:a053::1.
Now the interesting bit: I go to the other side, and ping *towards* the
NetBSD side. This works(!), and I can see NDP taking place in tcpdump:
20:29:14.317361 IP6 2001:608:4:a053::1 > ff02::1:ff01:0: ICMP6, neighbor
solicitation, who has 2001:608:4:a053::1:0, length 32
20:29:14.317665 IP6 2001:608:4:a053::1:0 > 2001:608:4:a053::1: ICMP6, neighbor
advertisement, tgt is 2001:608:4:a053::1:0, length 32
20:29:14.357624 IP6 2001:608:4:a053::1 > 2001:608:4:a053::1:0: ICMP6, echo
request, seq 1, length 64
20:29:14.357717 IP6 2001:608:4:a053::1:0 > 2001:608:4:a053::1: ICMP6, echo
reply, seq 1, length 64
and afterwards, I can see this neighbor in NDP:
$ SU ndp -a
Neighbor Linklayer Address Netif Expire S Flags
2001:608:4:a053::1 6e:02:b7:bc:b7:1d tap0 16s R R
and ping *from* the NetBSD side works as well - same command as before:
gert%zeta.medat.de@localhost:/home/gert$ ping6 2001:608:4:a053::1
PING6(56=40+8+8 bytes) 2001:608:4:a053::1:0 --> 2001:608:4:a053::1
16 bytes from 2001:608:4:a053::1, icmp_seq=0 hlim=64 time=54.365 ms
16 bytes from 2001:608:4:a053::1, icmp_seq=1 hlim=64 time=38.947 ms
... which tells me that all my routing setup should be correct.
Now, if I delete the NDP entry, I'm back where I started:
gert%zeta.medat.de@localhost:/home/gert$ SU ndp -d 2001:608:4:a053::1
2001:608:4:a053::1 (2001:608:4:a053::1) deleted
gert%zeta.medat.de@localhost:/home/gert$ ping6 2001:608:4:a053::1
PING6(56=40+8+8 bytes) 2001:608:4:a053::1:0 --> 2001:608:4:a053::1
ping6: sendmsg: No route to host
ping6: wrote 2001:608:4:a053::1 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:608:4:a053::1 16 chars, ret=-1
... again, no activity on the tap interface.
So, if I interpret this correctly, the NetBSD side of things is just not
doing NDP "on its own", but if the NDP cache entry is there, the tap
interface would work.
I've tried to understand how NDP works in the kernel, but that's a bit
too high for me, and the ideas I came up with ("unknown device type on
tap0") all do not really "ring true"...
So - someone who could share more insight here what's happening, or
how to debug this?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany
gert%greenie.muc.de@localhost
fax: +49-89-35655025
gert%net.informatik.tu-muenchen.de@localhost
Attachment:
pgp9UELDEDuQn.pgp
Description: PGP signature