The ip total length field gives the value in bytes of the ip header along with the data it contains. However, in the below image the byes are 00 00 but Wireshark has a total length 0f 2016. Can someone clue me in on how that is calculated?
asked 25 Nov '12, 12:13  Binyan |
2 Answers:
Sometimes valid IP packets from interfaces doing TCP segmentation offloading will have an IP length of 0, and Wireshark has a preference to handle that. The preference is probably set for you; note that if you turn it off, things will not work very well. For some reason, at least with Safari, Cloudshark isn't letting me download the packet; Chrome on OS X, and Internet Explorer 9 on a Windows 7 virtual machine, isn't doing so either. Perhaps Cloudshark is just completely broken. The Git-trunk version of tcpdump has code, compiled in if
and I think it's a Microsoft blog, so, while NetMon may show the field as having the value 0 (because its dissection is done based on protocol format descriptions, which might make it harder to show the inferred value of the field), it might still handle the packet correctly. Wireshark should probably note that this is a calculated value and that this is the result of TCP segmentation offloading; I've modified the code on the SVN trunk to do so. answered 25 Nov '12, 16:37  Guy Harris ♦♦ edited 25 Nov '12, 19:16
just remove (26 Nov '12, 03:14) Kurt Knochner ♦ That worked - I guess the (26 Nov '12, 12:05) Guy Harris ♦♦ |
O.K. it's really 0x0000 and Wireshark (1.9.0 SVN-46157) shows the length as 2016. As this is clearly wrong, I double checked with tcpdump and MS Netmon. tcpdump:
MS Netmon:
I would say, this is probably a bug in Wireshark. If Wireshark deduces the length from the rest of the frame, it should at least output some warning about the zero IP length (Expert Info and/or coloring of IP Length field). Please file a bug report at bugs.wireshark.org with a link to this question. Please provide the capture file in the bug report. Please also post the link to the bug here. Regards answered 25 Nov '12, 13:54  Kurt Knochner ♦ edited 25 Nov '12, 14:02 Well I would think it is an error if it wasn't for the fact that the # is correct. There really is 2016 bytes of data in the packet (20 bytes for ip header + 20 bytes for tcp header + 1976 bytes for HTTP post). I have a total of 6 post in ths file and 4 have this issue where there is a total length of 00 00 but the byte count is really right. (25 Nov '12, 14:07) Binyan
if it's a bug or not is up to the core developers to decide. However, there is no (full) plausibility check of the IP length in the code, so either this is by design or a bug ;-) (25 Nov '12, 14:42) Kurt Knochner ♦ there you have it. It's by design :-)) (26 Nov '12, 02:19) Kurt Knochner ♦ |
looks strange. Your screenshot shows 0x0000 where it should be 0x07E0.
Can you post that single packet as pcap file on cloudshark.org?
I've save the single packet as a pcap file but loudshark.org, doesn't resolve for me. Is that the correct address?
sorry, should have been cloudshark.org.
OK, here it is http://cloudshark.org/captures/25e40f73bc1c