http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1663
Summary: NFSv4 SETATTR not decoding properly
Product: Wireshark
Version: 0.99.5
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: chcosta75@xxxxxxxxxxx
Build Information:
Version 0.99.5 (SVN Rev 20677)
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.7, with GLib 2.12.7, 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 2000 Service Pack 4, build 2195, with WinPcap version 3.1
(packet.dll version 3, 1, 0, 27), based on libpcap version 0.9[.x], without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Overview Description:
A SETATTR Call, within a NFSv4 "Compound" message, does not decode properly.
Also, calls within the Compound that follow the SETATTR also do not decode
properly.
Steps to Reproduce:
I have a sample trace of such an NFS SETATTR Call that is not decoding.
1) Load the trace in Wireshark 0.99.5
2) Inspect the Packet Details and Packet Bytes panes of the NFS Call
containing the SETATTR.
Actual Results:
In the Packet Details pane, Opcodes after the SETATTR decode as "Unknown.
Highlighting the attr_vals -> contents field in the Packet Details, and then
looking at the Packet Bytes, shows the actual attr_vals encompass a different
byte sequence than Wireshark is highlighting.
Expected Results:
Wireshark should decode the SETATTR and subsequent operations correctly.
Additional Information:
I believe the problem is with the decoding of the SETATTR "State ID" field.
This field is broken into 2 separate fields, Sequence ID and Opaque Data.
These two fields occupy a *contiguous* 16 Byte space, however Wireshark is
decoding as if there are 4 bytes of "nothing" in between the 2 fields. This
skews the offsets for all the fields that follow and nothing beyond that point
decodes reliably.
--
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.
