In Wireshark, what does Follow TCP Stream show that the packet list cannot, and what does it do to your display filter?
answer
- sessions, not single packets
- payload placed by sequence, per direction
- client red, server blue
- a stream-index filter is left behind
- Back restores, Close keeps
basics
~20 sFollow TCP Stream rebuilds one connection's payload as the applications exchanged it, both directions in sequence order with retransmitted bytes shown once, and applies the display filter tcp.stream eq N, which Back removes and Close keeps.
solid answer
~50 sThe packet list shows segments; Follow TCP Stream shows the conversation. Wireshark takes the TCP payload of the selected connection, places each chunk by its sequence number, shows bytes that a retransmission repeats only once, and colours client data red and server data blue, for the entire conversation or one direction. Where the receiver acknowledged data that the capture never recorded, it inserts `[N bytes missing in capture file]` rather than silently joining the gap. It also applies the display filter `tcp.stream eq N`: **Back** closes the dialog and restores your previous filter, **Close** leaves the stream filter in place, and **Filter out this stream** hides that connection instead. You can view the data as ASCII, Hex Dump, UTF-8, YAML or Raw, save it with **Save as...**, and step to other connections with the Stream selector. It works whatever the TCP reassembly preferences are set to.
go deeper
Recall the menu path, the red and blue colouring of the two directions, and that the dialog leaves tcp.stream eq N behind as a display filter unless you press Back.
Explain that the dialog places payload by sequence number, shows retransmitted bytes once, and marks bytes the receiver acknowledged but the capture lacks.
Show that you treat a missing-bytes marker or a connection captured mid-flight as a property of the capture, and judge whether the stream is complete enough to support a conclusion.
Weigh what a reconstructed conversation can prove in an incident report, given where the capture was taken and what the capture host may have dropped.
## Why a stream view exists TCP delivers a **byte stream**, not messages. An HTTP request, an SMTP dialogue or a Telnet login is usually spread over many segments, interleaved with bare acknowledgments, and the packet list shows every frame on its own row. Reading a session that way means reassembling it in your head. **Follow TCP Stream** answers the question the packet list cannot: *what did the two applications actually say to each other?* It takes the payload of one TCP connection and lays it out as continuous text or bytes, one colour per direction. ## What happens when you follow a stream 1. Select any packet of the connection and choose **Analyze > Follow > TCP Stream** (the packet-list context menu has the same entry). 2. Wireshark looks up the connection's **stream index**, the number it gives every TCP conversation in the file, and applies the display filter `tcp.stream eq N`. 3. It collects the payload of each direction and places every chunk at its position in the sequence space, so segments captured out of order appear in order and bytes repeated by a retransmission appear once. 4. Where the receiving side acknowledged data that is not in the capture, it inserts a marker such as `[1460 bytes missing in capture file]`. 5. It opens the dialog with client-to-server data in **red** and server-to-client data in **blue**; the colours are set under **Appearance > Font and Colors** in the preferences. How sequence numbers order a byte stream is a TCP subject of its own; here it is enough that Wireshark uses them to put the bytes back in place. ## Reading the dialog | Control | What it does | |---|---| | Entire conversation / one direction | Show both sides, or only client to server, or only server to client | | Show as | ASCII, C Arrays, EBCDIC, Hex Dump, UTF-8, UTF-16, YAML or Raw | | Stream selector | Step to another stream index without leaving the dialog | | Find | Search for text inside the stream | | Save as... | Write the stream in the current format; **Raw** saves the bytes as a binary file | | Filter out this stream | Apply a display filter that hides this connection | | Back | Close the dialog and restore the previous display filter | | Close | Close the dialog and keep `tcp.stream eq N` applied | The **YAML** view lists the peers and, for every chunk, the original packet number, the peer, a timestamp and the data in base64, which is handy when a script has to consume the conversation. ## The display-filter side effect Many analysts use the dialog as the quickest way to isolate one connection: open it, press **Close**, and the packet list now holds only that stream. The flip side catches people out: the filter stays, and an hour later other traffic seems to have vanished. **Back** is the button that puts the old filter back. The filter is an ordinary display filter, so you can extend it by hand, for example to add a time window; the filter language itself is a separate subject. ## Where the view stops being trustworthy - **Capture gaps.** A `[N bytes missing in capture file]` marker means the receiver acknowledged bytes the capture point never recorded. That is a fact about the **capture** (a late start, drops on the capturing host), not proof that the network lost data, and anything you rebuild from the stream is incomplete at that offset. - **A connection already open when capture started.** Without the handshake, the first bytes you see may be the middle of a message. - **Encrypted payload.** Following the TCP stream of a TLS connection shows ciphertext. **Follow TLS Stream** shows plaintext only once Wireshark can decrypt the session, which needs the session's key material. - **Live captures.** The dialog does not update while capturing; reopen it to see newer data. - **Reassembly preferences.** Follow TCP Stream does not depend on them: it shows the payload in sequence order whether or not subdissector reassembly is enabled. ## Without the GUI `tshark` produces the same view for a ticket or a script. The data from the second node is indented with a tab, and in ASCII mode every chunk is preceded by its length: ```bash tshark -r download-0412.pcapng -q -z follow,tcp,ascii,7 ``` Stream index 7 is the eighth TCP conversation in that file, because the count starts at 0. Replace `ascii` with `hex`, `raw` or `yaml`, or give the two `address:port` endpoints instead of the index.
- What does `[2920 bytes missing in capture file]` in a Follow TCP Stream window tell you?The other side acknowledged 2,920 bytes of this direction that are not in the capture, so they reached the receiver but the capture point never recorded them. It is a capture-side gap, from a late start or drops on the capturing host, not evidence of loss on the network. Anything rebuilt from that stream, a file especially, is incomplete at that offset.
- How do you get the same conversation text without opening the Wireshark GUI?Run `tshark -r capture.pcapng -q -z follow,tcp,ascii,7` to print stream index 7 in ASCII; the second node's data is indented by a tab and each chunk is preceded by its byte length. Swap `ascii` for `hex`, `raw` or `yaml`, or name the two `address:port` endpoints instead of the index.
saying these in an interview costs you the question
- Follow TCP Stream prints the payload in capture order, retransmitted copies included.
- Closing the Follow dialog always puts the previous display filter back.
- Follow TCP Stream only works when TCP reassembly is enabled in the preferences.
- A gap marker in a followed stream proves the network dropped that data.
- Following the TCP stream of an HTTPS connection shows the HTTP requests inside it.