http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1889
Summary: NFSv3 filehandles being "returned" incorrectly.
Product: Wireshark
Version: 0.99.6
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: fschorr@xxxxxxxxxxx
Build Information:
Version 0.99.7-SVN-23040 (SVN Rev 23040)
Compiled with GTK+ 2.12.0, with GLib 2.14.1, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, 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
--
Wireshark is "returning" incorrect information for NFSv3 filehandles.
Although I found this problem while using MATE, there is two ways to see the
problem:
1: Open the attached capture fs-problem.cap, open the "packet bytes" window
then click on frame 3. In the Packet Detail window, open Network File System,
"what", "dir" and click on "filehandle". Although the "length field" is
showing 32 bytes, if you look in the "packet byte" window you'll notice that 48
bytes are highlighted. It appears that when clicking on the "filehandle" field
all bytes from the beginning of the filehandle to the END of the frame is
highlighted.
2: If you do a right mouse click on the same "filehandle" filed and pick
"prepare a filter" and "selected" the filter consisted of a 48 byte filehandle
nfs.fhandle ==
40:00:00:00:01:00:00:00:cb:87:09:00:9b:49:11:46:40:00:00:00:01:00:00:00:02:00:00:00:00:00:00:00:00:00:00:0b:41:31:30:45:43:47:4f:2e:6d:73:67:00
This again is the bytes from the beginning of the filehandle to the end of the
packet.
This same issue can be seen in each of the packets that have information in the
packet that occurs AFTER the filehandle (frames 3, 5 and 7).
In frame 1 the information returned for the FH APPEARS to be correct because
there is no byte information in the frame after the filehandle.
At the same time if you click in the FH "hash" field in frames 3, 5 and 7 the
correct 32 bytes for the filehandle is highlighted in the Packet Detail window.
Thanks you for your time,
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.
