Hello all, I have a packet capture with an expert analysis that doesn't appear to be valid. The packet capture is located at https://www.cloudshark.org/captures/67d2b4aed1d4 Here is what my own window looks like:
What leads me to believe that this is a bug in Wireshark is that there have been no actual retransmissions. I've opened up the pcap on multiple platforms (win7, mac, ubuntu) and all are reporting the same thing, so it's not a platform-specific issue. Another curious thing is that Cloudshark's expert analysis doesn't show the fragment overlap error. To see it yourself you'll need to download the pcap and view it in a desktop client. What I'm trying to do is verify that this is indeed not a network issue but instead anomalous behavior on the part of Wireshark. Thanks in advance, -Geoff asked 23 Jun '15, 08:59  glisk |
One Answer:
The problem with this capture is that the HTTP header indicates a Content-Length of 391048208 bytes, which is more than half of the TCP sequence number overlap value, thus defeating Wireshark logic when comparing sequence numbers. So at some point it considers that segment with sequence number 394 is greater than sequence number 391048208. answered 23 Jun '15, 18:18  Pascal Quantin |
I tried with 1.12.6 on Windows 7 64-bit and it seems like a bug to me. If you turn on TCP's "Validate the TCP checksum if possible" option, those "New fragment overlaps old data (retransmission?)" Expert Infos go away ... although you get 11 TCP "Bad checksum" Expert Infos instead.
By the way, I also tried with git-master and Wireshark crashed when I loaded the capture file. That might be a separate bug though, perhaps bug 10365.
I have played around withh the options and I found the following combination of Protocol Preferences which causes the strange output.
If one of these two options or both are deactivated, the error does not occur.