Hi,
first of all, thanks for your insights. Learned a lot today
("route -n monitor" and the "cloning" route stuff).
Now towards the actual thread:
On Fri, Sep 16, 2011 at 08:47:51PM -0400, Greg Troxel wrote:
> It seems there is a bug in tap.
>
> In systems derived from 4.4BSD, the connected route should appear
> automatically when adding an address. I would say it's a bug for
> systems that have the concept of cloning route not to add it
> automatically when configuring an address.
>
> summary: I tried to replicate on sparc64. Both it and i386 seem to work
> correctly.
Things seem to be a bit more complicated than thought...
I rebooted (to test whether different values of ip6mode have an effect,
and to clear whatever garbage my previous route/ifconfig fumbling might
have left somewhere), and that makes it work "for a while"(!):
# date
Sat Sep 17 09:14:57 CEST 2011
# ifconfig tap0 create
# ifconfig tap0 inet6 2001:608:4:a053::1:0/64
# date
Sat Sep 17 09:15:32 CEST 2011
# netstat -rn -f inet6 |grep :4:
2001:608:4:a053::/64 link#3 UC 0 0
- tap0
2001:608:4:a053::1:0 f2:0b:a4:00:02:7f UHL 0 0
- lo0
(I seem to get these "UHL / lo0" entries for all "local ip address"
values)
... and after a while:
# date
Sat Sep 17 09:19:16 CEST 2011
# netstat -rn -f inet6 |grep :4:
2001:608:4:a053::1:0 f2:0b:a4:00:02:7f UHL 0 0
- lo0
... and when that happens, it will stay that way "no /64 UC" even if
I destroy and recreate the tap0.
"route -n monitor" shows the withdrawal of the /64 UC route:
got message of size 248 on Sat Sep 17 09:19:05 2011
RTM_DELETE: Delete Route: len 248, pid 0, seq 0, errno 0, flags: <DONE,CLONING>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
2001:608:4:a053:: ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.2.7f
2001:608:4:a053::1:0
got message of size 108 on Sat Sep 17 09:19:05 2011
RTM_NEWADDR: address being added to iface: len 108, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: hme0:8.0.20.c0.ff.ee 2001:608:8003:0:a00:20ff:fec0:ffee
got message of size 168 on Sat Sep 17 09:19:05 2011
RTM_ADD: Add Route: len 168, pid 0, seq 0, errno 0, flags: <UP,HOST,LLINFO>
locks: inits:
sockaddrs: <DST,GATEWAY>
2001:608:8003:0:a00:20ff:fec0:ffee 8.0.20.c0.ff.ee
... and that makes me suspect it has to do with "ip6mode=autohost", as
the tap0 route disappears the very moment a SLAAC'ed IPv6 address shows
up on hme0.
Trying again with "ip6mode=host"...
$ netstat -rn |grep :4:
2001:608:4:a053::/64 link#3 UC 0 0
- tap0
2001:608:4:a053::1:0 f2:0b:a4:00:04:a6 UHL 0 0
- lo0
... waiting for incoming RA...
09:31:33.962892 IP6 fe80::21d:73ff:feb1:919c > ff02::1: ICMP6, router
advertisement, length 80
... route still there!
gert%zeta.medat.de@localhost:/home/gert$ netstat -rn |grep :4:
2001:608:4:a053::/64 link#3 UC 0 0
- tap0
2001:608:4:a053::1:0 f2:0b:a4:00:04:a6 UHL 0 0
- lo0
... and in this scenario, OpenVPN-on-TAP does what I want (and the extra
"route" statement for the connected /64 properly gets rejected with
"route: writing to routing socket: File exists")
So now this brings up more questions :-)
- what exactly does "ip6mode=autohost" change?
- should it have this effect (UC routes on interface A going away
if a RA is seen on interface B, while the ipv6 address is still there)?
[..]
> > fe80::f00b:a4ff:fe00:4dd2%tap0 f2:0b:a4:00:4d:d2 UHL 0 0 - lo0
>
> This one seems wrong. I have no such entry but instead have an ND cache
> entry. I suspect this and the missing cloning route are related.
I see "UHL... lo0" routes for all IPv6 addresses that the system has,
and "UHLc" for ND (+arp) cache entries:
$ netstat -rn |grep UHL
10.100.53.1 6e:02:b7:bc:b7:1d UHLc 1 60 - tap0
172.30.1.1 e4:1f:13:8e:80:b0 UHLc 0 32 - hme0
172.30.1.5 e4:1f:13:8e:80:b0 UHLc 4 6179 - hme0
172.30.1.199 00:a0:f9:00:7c:fa UHLc 1 0 - hme0
2001:608:4:a053::1 6e:02:b7:bc:b7:1d UHLc 2 8
- tap0
2001:608:4:a053::1:0 f2:0b:a4:00:0a:32 UHL 1 0
- lo0
2001:608:8003::beef 08:00:20:c0:ff:ee UHL 0 0
- lo0
2001:608:8003::ffff 00:1d:73:b1:91:9c UHLc 1 14
- hme0
fe80::21d:73ff:feb1:919c%hme0 00:1d:73:b1:91:9c UHLc 0 45
- hme0
fe80::a00:20ff:fec0:ffee%hme0 08:00:20:c0:ff:ee UHL 0 0
- lo0
fe80::1%lo0 link#2 UHL 0 0
- lo0
fe80::f00b:a4ff:fe00:a32%tap0 f2:0b:a4:00:0a:32 UHL 0 0
- lo0
... I have no idea whether it should be that way or not, but it's
the same on other NetBSD machines I've checked.
[..]
> Note that you are doing this on sparc64, which is LP64, and big endian.
> I predict that this will turn out to matter (but mine works).
Can't test on anything else, but this morning's test hint at "autohost"
side effects...
[..]
> > As a cross-check, I just tried this on NetBSD 3.1, and indeed, the route
> > auto-appears on tap0, and ND starts
> >
> > 22:20:00.348908 2001:608:4:a253::1:0 > ff02::1:ff00:2: icmp6: neighbor
> > sol: who has 2001:608:4:a253::2
> >
> > (different prefix deliberately chosen)
>
> What hardware?
Also Sparc64. Right now, I don't have an i386 installation available.
But that machine has "ip6mode=host" (default setting).
[..]
> I just did this on a sparc64 running 5.1_RC3. (I know that's old, and I
> will update to recent netbsd-5 and can try again if you're still having
> trouble.). After "ifconfig tap0 inet6 2001:db8::1", diff -u of "netstat
> -nr -f inet6" taken before and after shows:
>
> +2001:db8::/64 link#7 UC 0 0 - tap0 =>
Does this system has IPv6 on another interface, with incoming router
advertisements? How is "ip6mode" set? (Just cross-checking).
thanks again,
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:
pgp49p_oVoJJj.pgp
Description: PGP signature