# mount_nfs under ipv6 buggy?



## vh (Nov 12, 2012)

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:

```
[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


----------



## SirDice (Nov 12, 2012)

rpcbind(8) also needs to be specifically bound to an IP address too.

Also make sure your exports(5) allow the IPv6 network.


----------



## vh (Nov 12, 2012)

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.


----------



## vh (Nov 12, 2012)

Oops, I forgot to thank you for the answer!

Have a good evening,
Vincent


----------



## mamalos (Nov 13, 2012)

...just out of curiosity, does your configuration work on IPv4?


----------



## vh (Nov 14, 2012)

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


----------



## vh (Nov 14, 2012)

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


```
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â€¦


----------



## vh (Nov 14, 2012)

Oh, here is the culprit. If I have two IPv6 addresses, v6_1 and v6_2 reported thus by ifconfig:


```
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.


----------

