On Mon, Jun 28, 2021 at 6:35 PM Nick Couchman <nick.e.couchman@gmail.com> wrote:

On Mon, Jun 28, 2021 at 5:51 PM Frank Filz <ffilzlnx@mindspring.com> wrote:

Could you put the binary wire capture file somewhere? I find it a lot easier to read wire traces in wireshark UI…

 

Sure, here you go - I've done some editing to sanitize it a bit, but it should still show the overall flow:

https://drive.google.com/file/d/1PI22xjraWQ2b8HXJsySpoIkmrOe-ZIOe/view?usp=sharing

-Nick

Okay, added some additional debugging information and here's what I'm seeing...

* The FSINFO request over NFS triggers the nfs3_fsinfo call.

* This FSINFO request triggers a call to nfs3_FhandleToCache

* nfs3_FhandleToCache calls proxyv4_wire_to_host via the export->export.exp_ops.wire_to_host callback

* proxyv4_wire_to_host calls HandleMap_GetFH in the handle_mapping.c file.

* HandleMap_GetFH does the hashtable lookup and initially succeeds, but then fails in this section:

        rc = hashtable_getlatch(handle_map_hash, &buffkey, &buffval, 0, &hl);

        if (rc == HASHTABLE_SUCCESS) {
                handle_pool_entry_t *h = (handle_pool_entry_t *) buffval.addr;

                if (h->fh_len < fsal_handle->len) {
                        fsal_handle->len = h->fh_len;
                        memcpy(fsal_handle->addr, h->fh_data, h->fh_len);
                        rc = HANDLEMAP_SUCCESS;
                } else {
                        rc = HANDLEMAP_INTERNAL_ERROR;
                }
                hashtable_releaselatched(handle_map_hash, &hl);
                return rc;
        }

The statement "if (h->fh_len < fsal_handle->len)" apparently is not true (so h->fh_len is either greater than or equal to fsal_handle->len), and it skips down to the next section, assigning rc the HANDLEMAP_INTERNAL_ERROR value and then bails out.

-Nick