Ethereal-dev: [Ethereal-dev] NFS fhandle stateful matching

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>
Date: Mon, 20 May 2002 19:42:05 +1000
Hi Guy Uwe MikeF and other nfs friends

Updated stateful fhandle filtering patch.

As before, this patch adds an option to do stateful filtering for NFS
filehandles.
It supports all NFS related protocols currently implemented in ethereal,
e.g. NFS,
MOUNT, NLM (including Async NLM), KLM and NFSACL (when that ones dissectors
get implemented).

It is stateful in that sense that when enabled, if a nfs.fh.hash ,
nfs.fh.name or nfs.fh.full_name filter is applied to
search for a specific fhandle, not only will the packets where this fhandle
occurs be matched but also any
corresponding request/reply packet.
So, if nfs.fh.hash==0x12345678 would normally give you the NLM_LOCK_MSG
packet, with this
option also the corresponding NLM_LOCK_RES packet (which does not contain
the fhandle) be selected.

This is imho incredibly useful.


The drawback is that some 10-20 lines of fhandle specific code had to be
added to the oncrpc layer which
is very ugly. Now packet-rpc.c contains a block of code tyhat actually
relates to a specific datastructure
for NFS.
(not too bad since one can estimate that probably >90% of all oncrpc traffic
is nfs related)


There is still one bug/not-yet-implemented-feature :
The matching will not work properly but miss packets for such packets that
contains more than one fhandle.
Some, less interesting, NFS commands have multiple fhandles inside one PDU.
Neither will it find all responses for the case where due to retransmission
multiple NFS PDUs have been
collapsed into one single segment.

The first case is imho not interesting. The second case is not common in the
captures i work with.
This means that i am do not plan to add functionality to handle multiple
fhandles in one packet unless someone
steps forward to say they want that functionality.
If someone really wants this bug fixed, I can do that. Else I will just wait
until someone complains.
Fixing the bug would mess it up slightly but not much.


Unless anyone complains that the patch is ugly or wants something fixed I
will check it in tomorrow.
YHBW


The patch also includes a small enhancement to how the fhandle hash is
calculated to reduce the
number of collissions from 100% to something less than that for the
mountpoint fhandle for certain NFS implementations.

best regards
    ronnie s

Attachment: fhandle.patch.gz
Description: GNU Zip compressed data