10:41 p.m.
Huh. Can you LogDebug those values? It seems to me like that check should
be <= not strict less than.
On Mon, Jun 28, 2021 at 20:10 Nick Couchman <nick.e.couchman(a)gmail.com>
wrote:
On Mon, Jun 28, 2021 at 6:35 PM Nick Couchman
<nick.e.couchman(a)gmail.com>
wrote:
> On Mon, Jun 28, 2021 at 5:51 PM Frank Filz <ffilzlnx(a)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?us...
>
> -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