Hi,
First off, nice email address! Response is inline.
On Fri, Oct 26, 2012 at 1:27 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> 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.
OK, perfect, thank you very much. The NFS client is indeed
disconnecting and reconnecting. Despite my manual verification of the
packet, I figured the packet had to be malformed since Wireshark
wasn't decoding it. I am trying to implement kerberos security on top
of my NFS4 -> HDFS (Hadoop Distributed File System) proxy:
https://github.com/brockn/hdfs-nfs-proxy
So I need to figure out why the Linux RPC/NFS4 Client doesn't like my
packet response to it's NULL (GSS Initiate) request. I have the debug
flags turned on user /proc/sys/sunrpc/* but there isn't anything
logged to syslog.
Brock