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).Īs 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. I guess someone set up a capture job and limited the amount of bytes captured per packet to 96 bytes maximum. So the IP length is exceeding the packet length. You can also see in the frame header that the "Bytes on Wire" is 96 bytes, and the "Bytes captured" is also 96 bytes. 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). Consider the following IP header, captured with Wireshark: Notice the fields in the header: the IP version is IPv4, the header length is 20 bytes, the upper-level protocol used is TCP, the TTL value is set tu. in wireshark, frame 10 has ip.len' field consisting of zero-bytes. The minimum length is 20 bytes, and the maximum is 65,535 bytes.
Yes, this is most likely a capture issue. Total length the length of the entire packet (header + data).
0 kommentar(er)
