NFS V4 READ of file returns 0 bytes

I'm in the process of writing an NFS V4 client and am debugging the results with Wireshark. I'm unable to read a file.

Through OPEN followed by GETATTR, I've opened the file and confirmed it's the desired file by the matching length (1001 bytes).

I then try to READ a single byte of the file with offset 0 and length 1. The resulting reply returns 0 bytes of data, even though the EOF is false. Repeated calls to the read command yield the same result.

Is there parameters in open or read that I'm missing to actually read the file?

Wireshark Output

Open Call

Operations (count: 5): SEQUENCE, PUTROOTFH, OPEN, GETFH, GETATTR
    Opcode: SEQUENCE (53)
    Opcode: PUTROOTFH (24)
    Opcode: OPEN (18)
        seqid: 0x00000000
        share_access: OPEN4_SHARE_ACCESS_READ (1)
        share_deny: OPEN4_SHARE_DENY_NONE (0)
        clientid: 0x13f5c375a578cd7c
        owner: <DATA>
        Open Type: OPEN4_NOCREATE (0)
        Claim Type: CLAIM_NULL (0)
    Opcode: GETFH (10)
    Opcode: GETATTR (9)

Open Reply

Operations (count: 5)
    Opcode: SEQUENCE (53)
    Opcode: PUTROOTFH (24)
    Opcode: OPEN (18)
        Status: NFS4_OK (0)
        StateID
            [StateID Hash: 0x91a9]
            StateID seqid: 1
            StateID Other: 13f5c375a578cd7c00000000
            [StateID Other hash: 0x5b73]
        change_info
            Atomic: Yes
            changeid (before): 110
            changeid (after): 110
        result flags: 0x00000004, locktype posix
            .... .... .... .... .... .... .... ..0. = confirm: False
            .... .... .... .... .... .... .... .1.. = locktype posix: True
            .... .... .... .... .... .... .... 0... = preserve unlinked: False
            .... .... .... .... .... .... ..0. .... = may notify lock: False
        Delegation Type: OPEN_DELEGATE_NONE (0)
    Opcode: GETFH (10)
        Status: NFS4_OK (0)
        Filehandle
            length: 128
            [hash (CRC-32): 0xc5dcd623]
            FileHandle: 2b3e5cee938ee2b6afff448601a384b8ffc30bab28b5e2a4...
    Opcode: GETATTR (9)
        Status: NFS4_OK (0)
        Attr mask: 0x00000010 (Size)
            reqd_attr: Size (4)
                size: 1001

Read Call

Operations (count: 3): SEQUENCE, PUTFH, READ
    Opcode: SEQUENCE (53)
    Opcode: PUTFH (22)
        FileHandle
            length: 128
            [hash (CRC-32): 0xc5dcd623]
            FileHandle: 2b3e5cee938ee2b6afff448601a384b8ffc30bab28b5e2a4...
    Opcode: READ (25)
        StateID
            [StateID Hash: 0x91a9]
            StateID seqid: 1
            StateID Other: 13f5c375a578cd7c00000000
            [StateID Other hash: 0x5b73]
        offset: 0
        count: 1

Read Reply

Operations (count: 3)
    Opcode: SEQUENCE (53)
    Opcode: PUTFH (22)
        Status: NFS4_OK (0)
    Opcode: READ (25)
        Status: NFS4_OK (0)
        eof: 0
        Read length: 0
        Data: <EMPTY>

For anybody who runs into a similar situation, I was able to fix the problem by changing the cachethis flag in the SEQUENCE operation of the READ call from true to false.

   struct SEQUENCE4args {
           sessionid4     sa_sessionid;
           sequenceid4    sa_sequenceid;
           slotid4        sa_slotid;
           slotid4        sa_highest_slotid;
           bool           sa_cachethis; // ensure this is false
   };

Some of the behavior of the cachethis flag is described in RFC 5661, but the information does not include why this behavior occurred.

One possibility is that Amazon's implementation of the NFS spec has a bug in the behavior with sa_cachethis.