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)".
Created attachment 151704 [details] PCAP capture file that causes wireshark to misbehave
Seems to be still open in upstream but can you please check latest devel version wireshark-0.99.6-0.pre1?
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.
Can you update to latest rawhide/fc6 version please? Do you still experience the same problem?
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).
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
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.