So, the problem I reported earlier with failing to unmount was fixed
by the back-ported patch.
Now, another problem is reported by my user. In this case, they are
trying to mount an IPv6 NFS server using NFSv3. Kernel is 3.9.11+,
with patches to support binding mount points to local IP (v4/v6) addresses.
Some NFS over IPv6 mounts work fine, but some do not. A reboot of the
NFS client machine did not fix the problem.
I have tried to reproduce the problem locally, but so far everything works fine
for us.
>From my own app's logs:
# mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o srcaddr=4001:1::1:201,vers=3
# requested NFS version or transport protocol is not supported
When this problem happens, I do not see any network traffic when trying to mount.
I am curious if anyone else has seen errors similar to this?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Possibly dumb question, are you sure your srcaddr option works for all
protocols involved, including portmap, mount, and nfs?
Ben Greear <[email protected]> wrote:
> From my own app's logs:
> # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o
> srcaddr=4001:1::1:201,vers=3 # requested NFS version or transport
> protocol is not supported
> When this problem happens, I do not see any network traffic when trying
> to mount.
That sounds like the error that one would get when *mount* was compiled with
the v6-incompatible sunrpc library rather than tirpc.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
On 10/21/2013 04:44 PM, Weston Andros Adamson wrote:
>
> On Oct 21, 2013, at 5:32 PM, Ben Greear <[email protected]> wrote:
>
>> So, the problem I reported earlier with failing to unmount was fixed
>> by the back-ported patch.
>>
>> Now, another problem is reported by my user. In this case, they are
>> trying to mount an IPv6 NFS server using NFSv3. Kernel is 3.9.11+,
>> with patches to support binding mount points to local IP (v4/v6) addresses.
>>
>> Some NFS over IPv6 mounts work fine, but some do not. A reboot of the
>> NFS client machine did not fix the problem.
>>
>> I have tried to reproduce the problem locally, but so far everything works fine
>> for us.
>>
>> From my own app's logs:
>>
>> # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o srcaddr=4001:1::1:201,vers=3
>> # requested NFS version or transport protocol is not supported
>>
>> When this problem happens, I do not see any network traffic when trying to mount.
>
> Did you look for the mount protocol when getting a network trace (filter "rpc" in wireshark).
I saw zero NFS related packets on the wire when hitting this problem.
But, there could have been packets earlier that put it into a funky
state, or a bit less likely, they could have been going out some of the
other virtual interfaces on the system.
> Could you:
>
> 1) run "rpcdebug -m nfs -s mount" before mounting, post output of dmesg after mount fails.
>
> 2) add -v to the mount command and post the output
I can try this.
> 3) maybe get rid of srcaddr= option / post info about the ip configuration
I can't easily do this, as the user's setup requires the srcaddr to route properly
to the filer.
I am also going to run a kernel with printks added around all the EOPNOTSUPP
returns that I can find to try to track down what part of the kernel is
complaining.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Are you sure you don't have any firewall rules (remember ip6tables != iptables) blocking nfs, mount, portmap, etc?
We should be able to narrow things down when we see the outputs I asked for (rpcdebug, mount -v).
-dros
On Oct 21, 2013, at 11:18 PM, Ben Greear <[email protected]>
wrote:
> On 10/21/2013 05:20 PM, Jim Rees wrote:
>> Possibly dumb question, are you sure your srcaddr option works for all
>> protocols involved, including portmap, mount, and nfs?
>
> Well, I'm not sure, but it has been working pretty well so far. I
> could have missed something when porting to the 3.9 kernel, as these
> problems appear to be regressions since older code was working...
>
> Thanks,
> Ben
>
>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
On Oct 21, 2013, at 7:54 PM, Ben Greear <[email protected]>
wrote:
> On 10/21/2013 04:44 PM, Weston Andros Adamson wrote:
>>
>> On Oct 21, 2013, at 5:32 PM, Ben Greear <[email protected]> wrote:
>>
>>> So, the problem I reported earlier with failing to unmount was fixed
>>> by the back-ported patch.
>>>
>>> Now, another problem is reported by my user. In this case, they are
>>> trying to mount an IPv6 NFS server using NFSv3. Kernel is 3.9.11+,
>>> with patches to support binding mount points to local IP (v4/v6) addresses.
>>>
>>> Some NFS over IPv6 mounts work fine, but some do not. A reboot of the
>>> NFS client machine did not fix the problem.
>>>
>>> I have tried to reproduce the problem locally, but so far everything works fine
>>> for us.
>>>
>>> From my own app's logs:
>>>
>>> # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o srcaddr=4001:1::1:201,vers=3
>>> # requested NFS version or transport protocol is not supported
>>>
>>> When this problem happens, I do not see any network traffic when trying to mount.
>>
>> Did you look for the mount protocol when getting a network trace (filter "rpc" in wireshark).
>
> I saw zero NFS related packets on the wire when hitting this problem.
> But, there could have been packets earlier that put it into a funky
> state, or a bit less likely, they could have been going out some of the
> other virtual interfaces on the system.
Ok, I wanted to make sure you weren't just looking at port 2049...
>
>> Could you:
>>
>> 1) run "rpcdebug -m nfs -s mount" before mounting, post output of dmesg after mount fails.
>>
>> 2) add -v to the mount command and post the output
>
> I can try this.
>
>> 3) maybe get rid of srcaddr= option / post info about the ip configuration
>
> I can't easily do this, as the user's setup requires the srcaddr to route properly
> to the filer.
I just want to make sure it's not a configuration error, but the outputs of 1) and 2) will help us determine what's happening.
>
> I am also going to run a kernel with printks added around all the EOPNOTSUPP
> returns that I can find to try to track down what part of the kernel is
> complaining.
The rpcdebug part should help with that. Maybe you should turn on everything (rpcdebug -m nfs -s all) since it's just a (failed) mount.
-dros
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/22/2013 07:19 AM, Michael Richardson wrote:
> Ben Greear <[email protected]> wrote:
> > From my own app's logs:
>
> > # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o
> > srcaddr=4001:1::1:201,vers=3 # requested NFS version or transport
> > protocol is not supported
>
> > When this problem happens, I do not see any network traffic when trying
> > to mount.
>
> That sounds like the error that one would get when *mount* was compiled with
> the v6-incompatible sunrpc library rather than tirpc.
It works sometimes on the problem system, and it always (so far) works in our lab.
We tried NFSv3 over IPv4, NFSv4 over IPv4, NFSv3 over IPv6 and NFSv4 over IPv6.
We are using the standard 'mount' that comes with the OS (Fedora 14, in this case),
but we are re-compiling the mount.nfs binary, so perhaps there is still some
problem in how we compile it...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Oct 21, 2013, at 5:32 PM, Ben Greear <[email protected]> wrote:
> So, the problem I reported earlier with failing to unmount was fixed
> by the back-ported patch.
>
> Now, another problem is reported by my user. In this case, they are
> trying to mount an IPv6 NFS server using NFSv3. Kernel is 3.9.11+,
> with patches to support binding mount points to local IP (v4/v6) addresses.
>
> Some NFS over IPv6 mounts work fine, but some do not. A reboot of the
> NFS client machine did not fix the problem.
>
> I have tried to reproduce the problem locally, but so far everything works fine
> for us.
>
> From my own app's logs:
>
> # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o srcaddr=4001:1::1:201,vers=3
> # requested NFS version or transport protocol is not supported
>
> When this problem happens, I do not see any network traffic when trying to mount.
Did you look for the mount protocol when getting a network trace (filter "rpc" in wireshark).
Could you:
1) run "rpcdebug -m nfs -s mount" before mounting, post output of dmesg after mount fails.
2) add -v to the mount command and post the output
3) maybe get rid of srcaddr= option / post info about the ip configuration
-dros
>
>
> I am curious if anyone else has seen errors similar to this?
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2013 05:20 PM, Jim Rees wrote:
> Possibly dumb question, are you sure your srcaddr option works for all
> protocols involved, including portmap, mount, and nfs?
Well, I'm not sure, but it has been working pretty well so far. I
could have missed something when porting to the 3.9 kernel, as these
problems appear to be regressions since older code was working...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com