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

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

accept rate: 0%

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.

permanent link

answered 14 Sep '12, 23:44

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

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.

permanent link

answered 14 Sep '12, 15:47

Jasper's gravatar image

Jasper ♦♦
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 ♦♦

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.

permanent link

answered 16 Sep '14, 05:23

Qazi's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 14 Sep '12, 15:06

question was seen: 22,607 times

last updated: 16 Sep '14, 05:23

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