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

data length

0

![alt text][1]

Hi all,

I'm trying to understand the data length and segment length calculation. I tried to take the IP total length and subtract the Ip Header length and the Tcp Header length but there seem to a difference for some frames. What is the reason?

Cheers, A

asked 26 Jul '15, 21:00

adriannuix's gravatar image

adriannuix
6●2●2●4
accept rate: 0%

edited 29 Jul '15, 18:11

Could you post the packet on cloudshark or google drive so that it can be examined?

It is difficult to analyze with a screen shot.

(28 Jul '15, 10:21) Amato_C

2 Answers:

0

There the follwing length now:
Frame length: Total length of the Frame, including the Padding Fields (if present and needed) of the Ethernet Layer
Captured Length: Frame Length which is captured (Interresting if a filter has been used)
IP.TotalLength: Total Packet Length. from IP-Header until Layer 7 payload ends
TCP.SegmentLegth: Resulting TCP Payload and only calculated by Wireshark
TCP.HeaderLength: Is the length of the TCP Header, because header size is variabel

answered 28 Jul '15, 23:59

Christian_R's gravatar image

Christian_R
1.8k●2●6●25
accept rate: 16%

edited 02 Aug '15, 13:29

I updated the link for a full file.

Thank you

(29 Jul '15, 18:12) adriannuix

In the new trace I can´t see any uncommon length like at the old trace?!

(29 Jul '15, 20:43) Christian_R
In the new trace I can´t see any uncommon length like at the old trace?!

I have spotted some, for example Frame 51 and Frame 52.

(02 Aug '15, 16:09) Christian_R

0

The problem is that the packet was written to the trace file with an incorrect frame.len of 66 bytes. If the original ip.len was 58 bytes and it is traveling over ethernet (which adds 14 bytes to the frame.len) wireshark thinks that the packet is only containing ip header plus tcp header plus 12 bytes tcp timestamp options in total 52 bytes.)
This happens for more outbound packets.
The filter to find those is (frame.len==66 and ip.len gt 52) or frame.number ==51 or frame.number==17 or frame.number==31 or frame.number==69 or frame.number==77
. alt text This seems to be a problem with the packet capturing tool (tcpdump on linux?).
Given that the trace file is dated 28 Nov 1999 I believe the problem should have been fixed by now

answered 02 Aug '15, 13:13

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

edited 03 Aug '15, 00:38

@mrEEde: Just out of curiosity. What do you think about Frame51 and Frame52 in the trace? Look at the IP.ID and the TCP Checksum.

I think the Frame 52 is a corrupted version of Frame 51. Perhaps only in the capture file not really on the wire. (Because the corrupted Frame is always behind the original Frame).

(02 Aug '15, 16:06) Christian_R

Christian, frame 52 is not corrupted, it is an incomplete copy of frame 51 with no payload. As the tcp.checksum is calculated including the payload and the payload is missing, wireshark detects it as incorrect.
So the trace tool was trying to trace headers only but not only reduced the frame.cap_len to 66 bytes but also the frame.len which is incorrect.

(02 Aug '15, 23:34) mrEEde

@mrEEde: Thank you. So you think the same as I, that the strange frames only appear in the trace file. And the frames you posted in the picture of your updated answr are exactly the frames I have meant.

(03 Aug '15, 00:26) Christian_R