https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4975
Summary: NFSv4 usability enhancements (Info column summaries,
filterable fields)
Product: Wireshark
Version: 1.5.x (Experimental)
Platform: Other
OS/Version: All
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: ian.schorr@xxxxxxxxx
Created an attachment (id=4880)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4880)
packet-nfs.c patch
Build Information:
--
Submitting a patch with a number of enhancements to NFSv4 dissector usability.
Primarily the changes focus on 1) presenting packet summaries in a more
readable format (which is notoriously bad with NFSv4). Maximizing usefulness
of the Info column (which is very poorly utilized at the moment) and 2)
improving filterable fields.
There are many changes here that all evolved out of a single project. If this
needs to be split up into multiple bugs, let me know.
Major Changes:
- Add details in the Info column about what a given operation is doing. For
example, if a client is reading a file, instead of simply displaying "READ", it
now prints the filehandle, offset, and size of the read operation.
- There is more work that can be done to tweak this. For example, some
operations still have no new summary info. This is partly because I don't have
traffic captures with some operation types.
- Adds the concept of "most significant" NFS operations. Allows the user to
summarize only those operations in the Info column, or filter only on them.
- Virtually every NFSv4 packet contains many NFS operations. Currently all
of them are displayed, but in 99% of cases you'll only care about 1 or 2. For
example, if a client is OPENing a file, you'd want to see info about that
operation. You typically don't care that the client also did a PUTFH, GETFH,
GETATTR, ACCESS, another GETATTR. But sometimes GETATTR is the "most
significant" operation, and the dissector handles that.
- The user can turn this summarization on and off. It's on by default.
- This field is filterable. This makes it possible for to filter for
operations where GETATTR is the primary operation (since virtually every NFS
call requests this info, but only some packets are generated because the client
OS is explicitly asking for a GETATTR).
- This also lays some groundwork for NFSv4 SRT calculations so we can fix bug
1693.
- Implemented basic FH<->name mapping.
- NFSv2 and v3 have File Handle <-> Name mapping capability, which helps with
analysis. This adds basic support.
- More work needs to be done. "Full path name" mapping isn't yet supported.
Minor changes:
- Stop printing COMPOUND in the Info column for every packet.
- In NFSv4, 99.9% of all packets have an RPC type of "COMPOUND". Printing
"COMPOUND" just wastes valuable space in the Info column.
- Give the user the option to turn off printing NFS "tags" to the Info column.
- NFSv4 has a "tag" field that allows client OSes to place a label in the
packet. Typically this contains a basic description of the intent of the
packet (the upper-layer FS operation that triggered the NFS I/O). Usually this
is just the "most significant" operation in the packet.
- With the new "most significant" feature, the tag is typically redundant,
and so wastes valuable space in the Info column.
- Do not treat Operation types in Requests as different filterable objects.
- In practice this wasted a lot of users' time.
- Previously, if you wanted to filter on all OPEN operations, for example,
you'd need a filter like "nfs.argop4==18 || nfs.reop4==18". If you want to
filter many different operations, the filter always needs to be twice as long,
slowing the user down.
- The new syntax would just be "nfs.op4==18". This causes the user more work
if they want to filter on *only one* operation type and *only* requests or
responses, but this would be much more rare than cases where you want to filter
on both requests and responses.
- This is much more similar like other, similar protocols, like NFSv3 and
CIFS.
- Allow filtering of operations by name.
- Now if I want to filter on all OPEN and CLOSE calls, I can set up the
filter "nfs.opname==OPEN || nfs.opname==CLOSE", which means I don't have to
memorize that OPEN is opnumber 18 and CLOSE is 4, or waste time looking them
up.
- The only quirk is that the filter is case-sensitive, so a filter for
"nfs.opname==open" wouldn't work. I don't know if there's an easy way around
this.
- We should consider doing the same for NFSv2/v3 as well, though that's not
in this patch.
- Add a "|" in-between operation names in the Info column.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
