http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1692
Summary: Details of a NFSv4 "compound" frame is not brought up to
the Packet List for that frame
Product: Wireshark
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: fschorr@xxxxxxxxxxx
Build Information:
Version 0.99.6 (SVN Rev 22249)
Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.10.12, with GLib 2.12.12, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 6.4, with Net-SNMP 5.4, with ADNS, with Lua 5.1,
with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio
PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.1
(packet.dll version 4.0.0.901), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
Details of a NFSv4 is not brought up to the Packet List view for that frame. An
example of this is in frame three of the attached capture NFSv4.cap. All the
"info" field in the Packet List view shows is "COMPOUND CALL". Looking at the
same frame in the Packet Detail view and opening the "Operations" etry, there
are 7 operations, PUTFH, NVERIFY, GETATTR, ACCESS, LOOKUP, GETFH and GETATTR.
Information about these 7 "operations" should be pulled up and put in the
"info" field in Packet List view for this frame.
If you look at the capture/screen shot, the 12 frames shown all have either
"Compound Call or Compound Reply" instead of information about the type of
operations in the frames.
If you were just to look at the Packet List view for this capture, you would
have no idea of what is happening in the capture. You would be forced to go
into the Packet Details for each frame to understand what is going on in the
capture.
This might not seem like a problem in this small of a capture but when you are
looking at hundreds of thousands or millions of frame per day, you what to
spend all your analyzing time looking at the "info" information in the Packet
List window to understand the flow of the traffic and ONLY go into the Packet
Details window to look at the details on a few packets of interest.
This concept is followed pretty well by most of the decodes for the major
protocols including NFS2 and 3. The NFS4 decode needs to be brought up to this
standard to make it usable for heavy protocol analysis.
This appears to also have lead to a problem with Response Time calculations for
the "compound" frames which I'll add as a sperate bug.
Many thanks for your time and consideration.
Frank Schorr
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.