This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

IPv4 total length exceeds packet length

0

What would be causes for this expert info errpr "IPv4 total length exceeds packet length?

See trace below. https://www.cloudshark.org/captures/e21319ae9105

Frame 1 has this error (I think most frames do).

Is this a capture issue?

This trace was gathered from tcpdump-uw from VMware ESXi.

Or could it be a MTU issue?

asked 16 May '16, 13:48

gipper's gravatar image

gipper
30121216
accept rate: 0%


2 Answers:

0

It's probably some form of TCP segmentation offloading - if this is traffic between virtual machines, i.e. traffic not going over a real network, that might be happening at the VMware level - causing strange packets to be supplied to the packet capture mechanism.

answered 16 May '16, 13:54

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

0

Yes, this is most likely a capture issue. You can see in the IPv4 header of frame 1 that the total length is 8292, which is probably a jumbo frame (since it's iSCSI traffic it's highly likely that it is). You can also see in the frame header that the "Bytes on Wire" is 96 bytes, and the "Bytes captured" is also 96 bytes. So the IP length is exceeding the packet length.

I guess someone set up a capture job and limited the amount of bytes captured per packet to 96 bytes maximum. Problem is, the capture job should set "Bytes captured" accordingly, and keep the original true length as "Bytes on Wire" (which is what Wireshark does if you set it to capture only 96 bytes).

As far as I've checked there is only the -s parameter to have tcpdump-uw capture a specific amount bytes per packet, so if that's what was used I doubt you can change that behavior. If you need to fix this problem you can use TraceWrangler.

I also wrote a blog post some time ago about slicing: https://blog.packet-foo.com/2015/08/frame-bytes-vs-frame-file-headers/

answered 16 May '16, 13:59

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

1

Problem is, the capture job should set "Bytes captured" accordingly, and keep the original true length as "Bytes on Wire" (which is what Wireshark does if you set it to capture only 96 bytes).

Yes. In fact, any tool using a normal version of libpcap, atop a normal OS packet capture mechanism, would do that, so, if that's what happened, there's a bug somewhere in the capture mechanism, whether it's in tcpdump-uw, the libpcap it uses, or the packet capture mechanism that version of libpcap uses. @gipper should complain to VMware about this.

(16 May '16, 14:40) Guy Harris ♦♦

Yes, it's a good idea to have VMware fix this.

(16 May '16, 14:42) Jasper ♦♦