It seems I've found a discrepancy between reported bytes captured, TCP/IP and data length as well as calculation of "Next Sequence Number". Below is a "good" example where the "61558 bytes captured" corresponds with the TCP/IP and Data Length.
...and here is a "bad" example where the "65654 bytes captured" does not correspond with the TCP/IP and Data Length. Also visible here is the fact that Wirehark reports bad FCS - which I also doubt is correct. What's more important though, is that the "Next Sequence Number" is also seemingly wrong. This field is calculated by Wireshark and aids greatly in my troubleshooting, but less so when it's incorrect :-) The question is whether my finding is indeed due to a bug in Wireshark or due to the fact that TCP Offload is enabled on the server where these captures are taken? Wireshark version used: 1.10.10 and 1.12.4 on Windows 7 and Windows Server 2008 R2 Best Regards, Niels
asked 26 Mar '15, 12:20  NJL edited 26 Mar '15, 12:50 |
One Answer:
This does not look like a Wireshark bug to me. In the first example, you have a TCP calculated length of 61504 bytes, with a relative sequence number of 2697841. Wireshark correctly calculates the next expected sequence number to be: 2636337 + 61504 = 2697841. Although it's not shown, the IP total length field is almost certainly 61544, which is 61504 + 20 (standard IP header) + 20 (standard TCP header). And if you add 14 bytes for the Ethernet framing, you get 61558, which matches the number of bytes captured. All is good, as you already know. On to the second example then ... The number of bytes captured is indicated as being 65654. Subtracting the 14 bytes for the Ethernet header means that the IP total length field would have to be 65640; however, that number is bigger than the largest value that the field can handle, which happens to be 65535, since the field is an unsigned short (2-byte) field. If you convert 65640 to hexadecimal, you get 0x10068, and when you try to stuff that number into an unsigned short field, you lose the upper 0x10000, leaving you with only 0x0068. In decimal, 0x0068 is 104. So, I think you will find that the IP total length field is set to 104. When you subtract 20 bytes for a standard IP header and another 20 bytes for a standard TCP header, you end up with a TCP payload of 64 bytes. Wireshark then correctly calculates the next expected sequence number of 2699553 from the current relative sequence number of 2699489 + 64. Because there's a lot of extra "padding" following the 64 byte TCP payload (as indicated by the data in the IP total length) field, Wireshark interprets the last 4 bytes of that "extra" data as an invalid Ethernet FCS, which of course it isn't, but that won't stop Wireshark from trying to validate it whenever the Ethernet dissector's "Validate the Ethernet checksum if possible" preference is enabled. answered 26 Mar '15, 19:58  cmaynard ♦♦ Thanks for your in-depth explanation which of course makes perfect sense. :-) (26 Mar '15, 23:37) NJL |
Can you share a capture in a publicly accessible spot, e.g. CloudShark?
sanitize using TraceWrangler if necessary (https://www.tracewrangler.com)
I tried using TraceWrangler but after several tries it still messed up the important details. Most likely user error, but I gave up and used screenshots instead.