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> wrote:

On Mon, Jun 28, 2021 at 4:21 PM Frank Filz <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
            length: 25
            contents: 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