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

How does Wireshark reassemble TCP Segments

0
1

I am dealing with a packet capture that has two TCP packets that are re-assembled TCP. How can wireshark associate the two packets together? I am talking about TCP re-assembly, not IP header fragment offset usage to identify reassembly. In fact the IP header ID's are not even in sequence. I am curious how Wireshark can associate the two packets correctly when there are no identifiable correlation between the two packets?

asked 14 Sep '12, 15:06

Erik's gravatar image

Erik
1121
accept rate: 0%


3 Answers:

2

There are two parts in reassembling higher layer PDU's that are transported over TCP.

First of all (as Jasper mentioned) TCP uses sequence numbers to be able to re-order packets if they arrive out-of-order and also to resend segments that might have been dropped.

Secondly, the higher layer protocol must know how much data it is expecting. This is necessary for the higher layer protocols as TCP is providing a stream of data, so the protocol needs to know how to split the stream into PDU's.

The wireshark dissectors that perform TCP reassembly also know where the bounderies between PDU's are and in that way mimic the protocol.

As an example, the HTTP protocol has a few ways of identifying when an object has been completely transmitted.

  • The HTTP header is terminated by a "CR/LF CR/LF" sequence, so the HTTP dissector will tell the TCP dissector to collect more data until it has a "CR/LF CR/LF" in it's data (and so a full HTTP header PDU)
  • In HTTP/1.0 without "Connection: Keep-Alive", each object is simply sent as data until the server sends a FIN. Wireshark will do the same and the HTTP dissector will tell the TCP dissector to collect more data until it sees the FIN. It then has the full HTTP body PDU
  • When "Connection: Keep-Alive" is used, there is a "Content-Length: xxx" line in the HTTP header. The HTTP dissector will keep asking the TCP to collect more data until it has xxx bytes of data and it knows it has collected the whole HTTP body PDU.

Other protocols work the same way. They know how much data they need to collect and they tell the TCP dissector to keep re-assembling the data until they see a full PDU.

answered 14 Sep '12, 23:44

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

0

simple (well, in theory :-)) TCP uses sequence numbers to be able to reassemble the packets in the correct order on the receiving side, and that's what Wireshark does, too. So yes, there is a correlation, it is the TCP sequence number you can see in the TCP header decodes.

answered 14 Sep '12, 15:47

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

I do not believe it uses only that. As there are multiple packets that contain the same ack number, that do not form the entire reassembled packet. Wireshark obviously identified that they did not belong within the reassembled packet.

(14 Sep '12, 16:09) Erik

The ACK number is only used to signal what packets have been successfully received, and isn't used for reassembling incoming packet contents. Sequence numbers are incoming, ACK numbers are outgoing and are related to the other nodes' sequence numbering.

(15 Sep '12, 03:49) Jasper ♦♦

0

TCP sequence number is used for reassembling packets. There is also a Stream Index which helps in identifying that these packets are part of the same stream.

answered 16 Sep '14, 05:23

Qazi's gravatar image

Qazi
11112
accept rate: 0%