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

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%


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.

permanent link

answered 16 May '16, 13:54

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

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/

permanent link

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 ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×29
×26
×6

question asked: 16 May '16, 13:48

question was seen: 10,807 times

last updated: 16 May '16, 14:42

p​o​w​e​r​e​d by O​S​Q​A