4:51 p.m.
Could you put the binary wire capture file somewhere? I find it a lot easier to read wire
traces in wireshark UI…
Frank
From: Nick Couchman [mailto:nick.e.couchman@gmail.com]
Sent: Monday, June 28, 2021 2:40 PM
To: Frank Filz <ffilzlnx(a)mindspring.com>
Cc: Solomon Boulos <boulos(a)google.com>; Todd Pfaff <pfaff(a)rhpcs.mcmaster.ca>;
support(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Support] Re: Proxy FSAL - NFS4 -> 3
On Mon, Jun 28, 2021 at 4:28 PM Nick Couchman <nick.e.couchman(a)gmail.com
<mailto:nick.e.couchman@gmail.com> > wrote:
On Mon, Jun 28, 2021 at 4:21 PM Frank Filz <ffilzlnx(a)mindspring.com
<mailto:ffilzlnx@mindspring.com> > wrote:
Hmm, we do need to make that SEGFAULT not happen… Directories will be missing in life…
Yes, I'd agree this is not ideal behavior - I would think if Handle Mapping is enabled
and the directory does not exist, the process of configuring that export ought to be
completely stopped.
Get a tcpdump and look at where the handle that is causing the stale handle error is
coming from. Do we handle map the handles shared in READDIR?
I put the tshark output in a pastebin and replied with that to the previous e-mail. If I
can provide any more detail let me know. I think it's the root handle that is causing
it, since it happens during mount?? But this level of NFS detail is very new to me :-).
Actually I'm not sure this is in readdir, but actually during FSINFO processing, as
the NFS3ERR_STALE response comes directly after the client does a FSINFO request:
Frame 152: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on interface 0
Ethernet II, Src: Cisco_9d:5a:42 (8c:60:4f:9d:5a:42), Dst: b2:5a:dd:d6:98:58
(b2:5a:dd:d6:98:58)
Internet Protocol Version 4, Src: 10.1.2.5, Dst: 10.1.2.4
Transmission Control Protocol, Src Port: 889, Dst Port: 2049, Seq: 169, Ack: 65, Len: 124
Remote Procedure Call, Type:Call XID:0x76f80e97
Fragment header: Last fragment, 120 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 0111 1000 = Fragment Length: 120
XID: 0x76f80e97 (1995968151)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 3
Procedure: FSINFO (19)
Credentials
Flavor: AUTH_UNIX (1)
Length: 52
Stamp: 0x00000000
Machine Name: nfs-client.example.com <http://nfs-client.example.com>
length: 25
contents: nfs-client.example.com <http://nfs-client.example.com>
fill bytes: opaque data
UID: 0
GID: 0
Auxiliary GIDs (1) [0]
GID: 0
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System, FSINFO Call DH: 0xb2a31f30
[Program Version: 3]
[V3 Procedure: FSINFO (19)]
object
length: 24
[hash (CRC-32): 0xb2a31f30]
FileHandle: 4300038610102300006eb32fce0000000000000000000000
Frame 153: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: b2:5a:dd:d6:98:58 (b2:5a:dd:d6:98:58), Dst: Cisco_9f:f0:6a
(00:00:0c:9f:f0:6a)
Internet Protocol Version 4, Src: 10.1.2.4, Dst: 10.1.2.5
Transmission Control Protocol, Src Port: 2049, Dst Port: 889, Seq: 65, Ack: 293, Len: 36
Remote Procedure Call, Type:Reply XID:0x76f80e97
Fragment header: Last fragment, 32 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 0010 0000 = Fragment Length: 32
XID: 0x76f80e97 (1995968151)
Message Type: Reply (1)
[Program: NFS (100003)]
[Program Version: 3]
[Procedure: FSINFO (19)]
Reply State: accepted (0)
[This is a reply to a request in frame 152]
[Time from request: 0.000301532 seconds]
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Network File System, FSINFO Reply Error: NFS3ERR_STALE
[Program Version: 3]
[V3 Procedure: FSINFO (19)]
Status: NFS3ERR_STALE (70)
obj_attributes
attributes_follow: no value (0)
-Nick