Bug 235272 - Wireshark occasionally mucks up RxRPC/AFS packet decoding
Wireshark occasionally mucks up RxRPC/AFS packet decoding
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: wireshark (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
http://bugs.wireshark.org/bugzilla/sh...
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-04 15:22 EDT by David Howells
Modified: 2016-12-07 10:12 EST (History)
2 users (show)

See Also:
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 15:27:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
PCAP capture file that causes wireshark to misbehave (4.92 KB, application/octet-stream)
2007-04-04 15:22 EDT, David Howells
no flags Details

  None (edit)
Description David Howells 2007-04-04 15:22:43 EDT
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)".
Comment 1 David Howells 2007-04-04 15:22:43 EDT
Created attachment 151704 [details]
PCAP capture file that causes wireshark to misbehave
Comment 2 Radek Vokal 2007-05-24 07:19:57 EDT
Seems to be still open in upstream but can you please check latest devel version
wireshark-0.99.6-0.pre1?

Comment 3 David Howells 2007-05-24 08:35:18 EDT
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 04:08:48 EDT
Can you update to latest rawhide/fc6 version please? Do you still experience the
same problem?
Comment 5 David Howells 2007-07-12 06:48:34 EDT
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'
 16  46.516983 172.16.18.111 -> 172.16.18.91 AFS (RX) FS Request: fetch-status 
(132)
[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 02:46:23 EDT
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 http://fedoraproject.org/wiki/BugZappers
Comment 7 Bug Zapper 2008-05-06 15:27:50 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.