Follow a TCP stream in the browser
Reassemble a TCP conversation from its segments and read it as one transcript, in order, with each direction separable.
Open in ctfpalTCP is a byte stream pretending to be packets. What the application sent has no relationship to how it was cut up, so reading individual packets tells you almost nothing about the conversation - and reading a reassembled stream tells you almost everything. This is the single most useful operation in capture analysis and it is the one people skip.
Why segments are not messages
One application write() can become five packets, or five writes can become one. Retransmissions duplicate bytes, out-of-order delivery scrambles them, and a segment can overlap the one before it. Reassembly sorts by sequence number, drops the duplicates, and hands back the bytes in the order the application actually produced them.
What you find in one
- A shell. Commands one way, output the other. The whole session reads like a terminal transcript, because it is one.
- A Telnet login. The password, spread one character per packet, becomes a word.
- A file transfer. The response headers, then the body - which is the file.
- A custom protocol. Length prefixes and magic numbers become visible once the bytes are contiguous, and a protocol you can see the shape of is one you can decode.
Common questions
- Why is a stream shorter than the bytes the capture says it carried?
- Because the capture was truncated. A `tcpdump` run with a snapshot length shorter than the packet - the old default was 68 bytes - records the headers and throws the payload away. The packet count is right and the payload is genuinely not there.