On Oct 25, 2012, at 6:04 PM, Brock Noland <brock@xxxxxxxxxxxx> wrote:
> I have some NFS 4 packets which are not decoding as NFS. As such they
> show up as RPC "Continuation Data" I would like to force parsing them
> in hopes of figuring why they are malformed. However when I right
> click and then go to "Decode as" NFS is not an option. Other NFS
> packets are decoding just fine. I have observed this with 1.8.3 MacOS
> and 1.2 RHEL 6.3.
>
> Is there anyway to force decoding as NFS in hopes of finding the parse error?
No.
NFS doesn't run atop UDP or TCP or..., it runs atop ONC RPC:
http://tools.ietf.org/html/rfc5531
A complete and valid ONC RPC request contains a program number, so it could be identified as an NFS request, and a version number, so it could be identified as an NFSv4 request. A complete and valid ONC RPC reply has neither; protocol analyzers determine the program and version of a reply by keeping track of the requests seen earlier in the capture and looking for a request with a matching transaction ID (xid) from the host to which the reply is being sent. A "decode as" for replies would be able to force dissection of the reply as NFSv4 - *BUT*, in order to dissect an ONC RPC request or reply, you also need the *procedure* number, which is also present in the request but not in the reply, so merely identifying a reply as NFSv4 would be insufficient to dissect it.
> Hex including below for the heck of it.
OK, let's look at it - I'm assuming this is at the ONC RPC layer, given that the first 32-bit word looks like an ONC RPC-over-TCP record marker.
> 800000b8
OK, if that's an ONC RPC-over-TCP record marker, the high-order bit is set, so it's the last (or only) fragment of a request or reply; the length of the fragment is 0xb8, or 184 bytes.
> a4890032
And if this is the only fragment, and thus the first fragment, that's the XID of a request or response...
> 00000001
...and that's an indication that this is a reply (0 = call, i.e. request, 1 = response, i.e. reply).
> 00000000000000060000001c040405ff
> ffffffff000000000fc3508e5cb32d64
> cf0493de76703e9a0000000000000004
> c0b2a463000000000000000000000080
> 0000006c606a06092a864886f7120102
> 0202006f5b3059a003020105a1030201
> 0fa24d304ba003020112a244044236e1
> 4ab6b70b0be7fe9ff07febd3cc676f99
> 339b3a2afc88aeadcde419b6778fd275
> 9d3518a5ecd809b0d639248d6c57a156
> 5451832f90075d21d8b653f4028b6307
...and that's 11*16, or 176, additional bytes, for a total of 176+8 = 184, so that's the entire fragment, and thus the entire reply.
If Wireshark hasn't found a request, on the same TCP connection, with an XID of 0xa4890032, then it has no idea what the program number, version number, or procedure number of the reply is - so, even if it were forced to dissect it as NFSv4, it wouldn't know which procedure it was. In the case of NFSv4 (but *NOT* any other version of NFS!), it could perhaps assume that any reply larger than a certain minimum size had to be a COMPOUND reply rather than a NULL reply.
The packet is probably not malformed - it's probably just the first NFSv4 packet on the connection, so that the corresponding request isn't in the capture. The reason it's marked as ONC RPC is probably that you're doing this in Wireshark, and you've already read in the capture, so the TCP connection has been marked as running ONC RPC; in that case, it arguably should at least dissect the ONC RPC header, even if it can't dissect the actual reply, to make it clearer that it's a reply that can't be dissected because we don't have the corresponding request.
