Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 235272

Summary: Wireshark occasionally mucks up RxRPC/AFS packet decoding
Product: [Fedora] Fedora Reporter: David Howells <dhowells>
Component: wiresharkAssignee: Radek Vokal <rvokal>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: lemenkov, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: wireshark-1.0.0-1.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 19:27:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
PCAP capture file that causes wireshark to misbehave none

Description David Howells 2007-04-04 19:22:43 UTC
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 -> AFS (RX) FS Request: fetch-status 

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)".

Comment 1 David Howells 2007-04-04 19:22:43 UTC
Created attachment 151704 [details]
PCAP capture file that causes wireshark to misbehave

Comment 2 Radek Vokal 2007-05-24 11:19:57 UTC
Seems to be still open in upstream but can you please check latest devel version

Comment 3 David Howells 2007-05-24 12:35:18 UTC
I downloaded wireshark-0.99.6-SVN-21916 and tried that, if that's the same 
thing.  That appears to be the latest devel code drop as of today.  It also 
seems to exhibit exactly the same broken behaviour.

I don't see where to get the -pre1 release from.

Comment 4 Radek Vokal 2007-07-12 08:08:48 UTC
Can you update to latest rawhide/fc6 version please? Do you still experience the
same problem?

Comment 5 David Howells 2007-07-12 10:48:34 UTC
I tried downloading the FC6 version (wireshark-0.99.6-1.fc6.i386.rpm and 
libpcap-0.9.4-10.fc6.i386.rpm) but it doesn't seem to fix anything:

[root@hades dhowells]# tshark -r /warthog/afs/dodgy-wireshark.pcap | grep ' 
 16  46.516983 -> AFS (RX) FS Request: fetch-status 
[root@hades dhowells]# tshark -v
TShark 0.99.6
Running on Linux 2.6.18-1.2798.fc6, with libpcap version 0.9.4.

Built using gcc 4.1.2 20070626 (Red Hat 4.1.2-13).

Comment 6 Bug Zapper 2008-04-04 06:46:23 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out

Comment 7 Bug Zapper 2008-05-06 19:27:50 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.