mount_nfs under ipv6 buggy?

V

vh

Hi folks,

I am running a couple of boxes under FreeBSD. The first one is somewhat old and uses the 8.0 release, whereas the second one is almost brand new and was shipped with 9.0-RELEASE-p3.

Now, the first box has a main IPv6 address, let’s say prefix1::1 and an alias, prefix1::cafe:fade.
I have set nfsd and mountd up to listen to the alias address (-h flag).

If now I try to mount the exported slice on my second box by using mount_nfs -o … box1_ip6_alias:slice /something, where ‘box1_ip6_alias’ is defined in /etc/hosts as a litteral for prefix1::cafe:fade, I get a failure in the form of a connection refused message:
Code: 
[tcp6] box1_ip6_alias:/home/www: nfsd: RPCPROG_NFS: RPC: Remote system error - Connection refused
If I try telnet box1_ip6_alias nfsd, it works correctly (the connection is accepted).

Using tcpdump(1), I just noticed that, albeit box1_ip6_alias is used, the destination address used by mount is prefix1::1.
Indeed, if I change the binding of the nfsd and mountd daemons to prefix1::1, it works, and I am able to mount the slice whatever IPv6 in the /64 I use.

Any explanation? Known behavior? Any further elaboration?

Thanks a lot!
Vincent
 
Well, if rpcbind and exports weren’t fit for ipv6, I suppose I would get no connectivity at all.
Besides, rpcinfo gives that:
[…]

100005 1 udp6 ::.3.12 mountd superuser
100005 3 udp6 ::.3.12 mountd superuser
100005 1 tcp6 ::.3.12 mountd superuser
100005 3 tcp6 ::.3.12 mountd superuser
[…]
100003 2 udp6 ::.8.1 nfs superuser
100003 3 udp6 ::.8.1 nfs superuser
100003 2 tcp6 ::.8.1 nfs superuser
100003 3 tcp6 ::.8.1 nfs superuser

which is, AFAIK, correct.

And, anyhow, the problem seems to be on the client side, where the IPv6 packet have a wrong destination.
 
Oh yes, it worked like a charm with IPv4, until I received word from my hosting company that they had run out of v4 addresses, and so they begged people using extra v4 to give them back. That’s what I did, and set an IPv6 bridge up instead. But I ran into this issue.

Cheers!
Vincent
 
It seems the initial request to rpcmapper is correctly sent to the right address:

Code: 
16:09:40.314961 IP6 (hlim 61, next-header UDP (17) payload length: 108) ovh2.mac-srvr-admin > 2001:41d0:2:87c3::cafe:fade.sunrpc: UDP, length 100
	0x0000:  6000 0000 006c 113d 2001 41d0 0002 ced2  `....l.=..A.....
	0x0010:  0000 0000 0000 0001 2001 41d0 0002 87c3  ..........A.....
	0x0020:  0000 0000 cafe fade 0294 006f 006c ce1c  ...........o.l..
	0x0030:  50ab a7e4 0000 0000 0000 0002 0001 86a0  P...............
	0x0040:  0000 0004 0000 000b 0000 0000 0000 0000  ................
	0x0050:  0000                                     ..
16:09:40.315161 IP6 (hlim 64, next-header UDP (17) payload length: 164) 2001:41d0:2:87c3::cafe:fade.sunrpc > ovh2.mac-srvr-admin: UDP, length 156
	0x0000:  6000 0000 00a4 1140 2001 41d0 0002 87c3  `......@..A.....
	0x0010:  0000 0000 cafe fade 2001 41d0 0002 ced2  ..........A.....
	0x0020:  0000 0000 0000 0001 006f 0294 00a4 4408  .........o....D.
	0x0030:  50ab a7e4 0000 0001 0000 0000 0000 0000  P...............
	0x0040:  0000 0000 0000 0000 0000 0001 0000 0017  ................
	0x0050:  3230                                     20
So the response is correct, but thereafter mount tries to contact nfsd on the wrong address, and the mount fails…
 
Oh, here is the culprit. If I have two IPv6 addresses, v6_1 and v6_2 reported thus by ifconfig:

Code: 
ifconfig ix0

ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=5bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO>
        …
	inet6 v6_1 prefixlen 64 
	inet6 v6_2 prefixlen 64 
       *beep*…

Then mount_nfs contacts only v6_1, even if rpcbind, nfsd and mounted are listening on v6_2… If I invert the order of v6_1 and v6_2, it works.
 
You must log in or register to reply here.
Back
Top