Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 1556] New: Wireshark occasionally mucks up RxRPC/AFS packet decoding

[bugzilla-daemon@xxxxxxxxxxxxx]

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.