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@mindspring.com> Cc: Solomon Boulos <boulos@google.com>; Todd Pfaff <pfaff@rhpcs.mcmaster.ca>; support@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@gmail.com <mailto:nick.e.couchman@gmail.com> > wrote: On Mon, Jun 28, 2021 at 4:21 PM Frank Filz <ffilzlnx@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