Hi list, Guy, Uwe, MikeF and any other friends of NFS.
Attached is a patch which is a work in progress. I did not commit it for CVS
for several reasons:
1, it is not finished yet, (No support for async nlm, or multiple fhandles
in one nfs packet)
2, it needs to be optimized a bit
3, feels too close to new version release
Please comment:
The patch adds one new option to NFS which will affect NFS and all support
protocols, such as KLM, NLM, MOUNT NFSACL which deals with fhandles.
The option stores state regarding which frames certain fhandles have been
seen in so that enabling this option
then e.g. nfs.fh.{hash|name|full_name}==xxx will not only find the packet
where this fhandle was found in but
also that packets matching request/response packet.
I.e. IF the display filter 'nfs.fh.hash==0x12345678' would normally find
request frame X which contains this
fhandle, then by enabling this option the filter will ALSO find and display
response frame Y.
(assuming Y is the reponse matching request X)
Functionality which may be very useful when dissecting NFS.
By enabling the option and filtering for a specific fhandle you not only see
the specific request packets where
this filehandle occurs but also the result in the matching response packets.
Well, in order to do this type of matching I had to add some code in
packet-rpc.c, i.e. in the layer below
since this is the only common codepath for all these protocols.
I find it ugly to add a 10-15 line block related to specific datastructures
inside the NFS protocol in the
generic ONCRPC dissector but could not come up with any better solution.
Comments please, does the functionality outweigh the ugliness of poisoning
packet-rpc.c
(I think so for my needs, but would like second opinions before checking in
something like this.)
or are there better ways to do this?
If no one responds or vetoes it I will check it in after the next release of
ethereal.
best regards
ronnie sahlberg
Attachment:
fhandle.diff.gz
Description: GNU Zip compressed data