Following a stream
Follow reassembles one TCP conversation in order. Encrypted bytes stay encrypted unless you were given the keys.
One conversation, both directions
Right-click a TCP frame and choose Follow, then TCP Stream. Wireshark builds the payload in sequence-number order, paints the two directions in two colors, and sets the display filter to that stream, written tcp.stream eq N. The same filter with == is the same test. You can type tcp.stream == 7 yourself once you know the index from a column.
The dialog shows what the TCP payload carried, with retransmission copies removed. It does not show the IP headers, and it will not invent bytes the capture never had. A snap length that cut the payload shows up here as a short, unsatisfying reconstruction. That is a property of the file, already decided at capture time.
tcp.stream == 7
TCP, HTTP, and TLS are different follows
Follow TCP Stream shows the bytes above TCP. If those bytes are TLS records, you see records, not a web page. Follow HTTP Stream runs after the HTTP dissector has reassembled a cleartext message, so it is the right follow for a lab server that spoke HTTP. Follow TLS Stream shows the decrypted application data only when a key log or other configured secret could open that session.
Turn on TCP reassembly in the TCP preferences when a message spans segments and the dissector looks confused. The preference changes the decode. It does not change the file. If a teammate’s screen disagrees with yours, compare that preference before you compare the capture.
Worked case: the login spans three segments
A cleartext lab login to 10.8.0.20 shows the POST line in frame 50 and the form body in frames 51 and 52. The Info column on frame 50 does not contain the password, because the body had not arrived yet. Follow HTTP Stream on frame 50 reconstructs one request: the request line, the headers, and the body. You can see that the body arrived, and you can see which stream carried it.
The same follow on a TLS session to port 443 shows opaque application data. The Client Hello’s server name is still readable in the details tree of the handshake frame, because that field sits in the handshake, not in the encrypted records. Follow did not fail. It showed you the layer you asked for. The password, if one was sent, is inside the records you cannot read without the client’s key log.
Quote the stream, not a screenshot of the dialog
The finding names tcp.stream, the two addresses, the ports, and the frame range. A screenshot of the follow dialog is optional and often crops the part a reviewer needs. Export specified packets for that stream if the rest of the file is noise or is too sensitive to pass around.
Close the dialog and clear the filter when you are done, or the next statistic will silently describe one stream. The filter tcp.stream eq N stays in the box until you remove it.
Diagram
From one row to the bytes of that conversation, in order
- Row
Start on a frame that belongs to the conversation.
- Follow
Follow TCP Stream for the payload, or HTTP Stream when the message is cleartext HTTP.
- Filter
The box now holds the stream index. The other conversations are hidden, not deleted.
tcp.stream == 7
- Layer
TLS application data stays opaque here unless a key log for this client is loaded.
Check yourself
1. A POST body is split across three TCP segments on a cleartext lab server. How do you read it as one message?
2. You follow a TLS stream and see ciphertext. What does that mean?
3. You close the follow dialog and Conversations looks tiny. What should you check?