http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1556
Summary: Wireshark occasionally mucks up RxRPC/AFS packet
decoding
Product: Wireshark
Version: 0.99.5
Platform: PC
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235
272
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: rvokal@xxxxxxxxxx
Build Information:
wireshark 0.99.5
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.8, with GLib 2.12.9, with libpcap 0.9.4, with libz
1.2.3, with libpcre 6.6, with Net-SNMP 5.3.1, without ADNS, without Lua, with
GnuTLS 1.4.1, with Gcrypt 1.2.3, with MIT Kerberos, without PortAudio, without
AirPcap.
Running on Linux 2.6.20-1.2944.fc6PAE, with libpcap version 0.9.4.
Built using gcc 4.1.1 20070105 (Red Hat 4.1.1-51).
--
Description of problem:
Wireshark occasionally incorrectly decodes the operation ID in an RxRPC
request packet. This is most noticeable in AFS FS requests, probably because
the AFS client makes a lot more of different types of these than any others.
For instance, in the attached PCAP file are 20 RxRPC packets (plus four ARPs).
If you look at packet #16 with tshark, you'll see this:
16 46.516983 172.16.18.111 -> 172.16.18.91 AFS (RX) FS Request: fetch-status
(132)
This is incorrect. The operation ID in the packet is actually 130 (0x82 -
fetch-data). This can be confirmed by loading the PCAP file into the
wireshark GUI and selecting the "Operation" field. This causes the op ID to
be highlighted in the hex dump of the packet. Furthermore, a fetch-data op is
what I'd expect to see at this point, not a fetch-status op.
Version-Release number of selected component (if applicable):
The bug occurs on FC5, FC6 and rawhide at least.
How reproducible:
The bug doesn't always manifest itself. It usually does with a very large
quantity of packets (a few hundred).
However, with the attached PCAP file, it's 100% reproducible with tshark and
wireshark both.
Steps to Reproduce:
1.tshark -r dodgy-wireshark.pcap | grep ' 16'
Actual results:
Operation is reported as "FS Request: fetch-status (132)".
Expected results:
Operation should be reported as "FS Request: fetch-data (130)"
PCAP capture file that causes wireshark to misbehave
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151704
--
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.
