Date: Tue, 15 Apr 2014 17:01:21 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: araujo@FreeBSD.org Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4: prob err=10036 Message-ID: <1786007789.11586463.1397595681788.JavaMail.root@uoguelph.ca> In-Reply-To: <CAOfEmZg9ejea%2B8Ab-cHS4Y99HZK-pK3kHD3o_Gih0y%2BQY0niJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcelo Araujo wrote: > > Hello Rick, > > > Thanks by the prompt reply, and I'm sorry my late reply, > unfortunately I'm located in Taiwan, so, timezone is an issue. > > > So here attached is my pcap. > > > Server IP: 172.17.32.42 > Client IP: 172.17.32.54 > > > Something related with RELEASE_LOCKOWNER, I'm still investigating, > maybe I can find a solution before you reply, if yes, I will post > here. > Well, I looked at the packet trace and it is weird. One field (the NFSv4 operation #) is incorrect in the packet. It should have been 33 (0x21), which is PUTROOTFH and instead it is 39 (0x27), which is RELEASELOCKOWNER. All the arguments after the operation # are correct for the RPC, if that operation# was 33 (PUTROOTFH). Since the call looks like this (around line#4303 in sys/fs/nfsclient/nfs_clrpcops.c): nfscl_reqstart(nd, NFSPROC_PUTROOTFH, nmp, NULL, 0, &opcntp, NULL); I can't imagine how NFSPROC_PUTROOTFH became NFSPROC_RELEASELCKOWN? (Btw, there is a mapping from NFSPROC_xxx to NFSV4OP_xxx that occurs, so these arguments are 33 and 34 respectively and not 33 and 39.) So, somehow the argument gets incremented by one when it is on the stack for the call. (It would be 34 in nfscl_reqstart(), since the tag is "Rellckown" and not "Dirpath" in the packet header. This tag is for debugging only and doesn't affect the RPC's semantics. For once, it was useful;-) So, this isn't some data error later, such as "on the wire". All I can suggest is that something is stomping on this field on the stack or there is a memory problem where this stack argument sits? Aren't computers fun? rick > > Thanks again. > > > > 2014-04-14 22:00 GMT+08:00 Rick Macklem < rmacklem@uoguelph.ca > : > > > > Marcelo Araujo wrote: > > Hi all, > > > > Anyone have saw this prob err before when try to mount a NFSv4? > > > > machine_a# mount -t nfs -o nfsv4 192.168.2.100:/a /mnt/ > > machine_a# mount_nfs: /mnt, : Input/output error > > machine_a# tail /var/log/messages |grep nfsv4 > > Apr 13 17:03:33 ESSD46B6E kernel: nfsv4 client/server protocol prob > > err=10036 > > > Well, 10036 is NFSERR_BADXDR (they are all in sys/fs/nfs/nfsproto.h). > This means that the server didn't like the RPC message presented to > it. > (I have no idea why that would be the case for machine_a?) > > If you capture packets while attempting the mount, you can look at > them in wireshark and maybe see how they are trashed? (I just got > home, > so I can take a look at a packet capture, if you email it to me as an > attachment.) > # tcpdump -s 0 -w mnt.pcap host 192.168.1.100 > - run on machine_a during the mount attempt, should do it (in > mnt.pcap). > > rick > > > > I have another machine with the same settings that can mount > > successfully > > the same NFSv4 share. > > > > machine_c# mount -t nfs -o nfsv4 192.168.2.100:/a /mnt/ > > machine_c# > > > > Best Regards, > > -- > > Marcelo Araujo > > araujo@FreeBSD.org > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to " > > freebsd-fs-unsubscribe@freebsd.org " > > > > > > > -- > Marcelo Araujo > araujo@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1786007789.11586463.1397595681788.JavaMail.root>