IPv4 total length exceeds packet length

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.

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/