skip to content

In Wireshark 4.6, what do the TCP preferences 'Allow subdissector to reassemble TCP streams' and 'Reassemble out-of-order segments' each change in the packet list?

level: middleimportance: should knowfreq 21%

answer

  1. messages larger than one segment
  2. decoded on the last segment
  3. one on by default, one off
  4. the second needs the first
  5. a real gap never fills

basics

~20 s

'Allow subdissector to reassemble TCP streams', on by default, lets HTTP or TLS decode a message spanning segments on its last segment; 'Reassemble out-of-order segments', off by default and dependent on it, also buffers early-arriving segments into that message.

solid answer

~50 s

With **Allow subdissector to reassemble TCP streams** on, the default, a dissector such as HTTP or TLS can ask TCP for more bytes, so a message spread over several segments is decoded once, on the frame holding its **last** segment, which also gains a "Reassembled TCP" tab in the bytes pane. The earlier segments show `[TCP PDU reassembled in N]` and carry `tcp.reassembled_in`. Turned off, every segment is decoded alone: HTTP bodies show as "Continuation" and TLS records as "Ignored Unknown Record", which saves memory when only sequence analysis matters. **Reassemble out-of-order segments** is off by default in 4.6 and works only with the first preference, and TCP sequence analysis, switched on. When a gap appears it buffers later segments, assuming the missing ones will arrive. If the capture really dropped them, the message never completes, so turning it off gives a partial dissection. Follow TCP Stream ignores both settings.

code

bash · 5 lines
bash
tshark -r upload-0412.pcapng -2 \
  -o tcp.desegment_tcp_streams:TRUE \
  -o tcp.reassemble_out_of_order:TRUE \
  -Y 'http.request' \
  -T fields -e frame.number -e tcp.stream -e http.request.uri

go deeper

for a junior

Recall that Wireshark shows a multi-segment HTTP or TLS message on its last segment and that the earlier segments point to it.

for a middle

Explain both preferences, their defaults, their dependency, and the Continuation and Ignored Unknown Record symptoms that appear when reassembly is off or the stream has a gap.

for a senior

Show when you would flip each setting on a lossy or reordered capture, and that a message that never completes points at the capture before it points at the network.

for a principal

Weigh analyser memory and two-pass processing time against decode fidelity when a team standardises preference profiles for very large captures.

## Why an analyser has to reassemble TCP carries a **byte stream** and knows nothing of message boundaries. An HTTP response or a TLS record is often far larger than one segment, so a dissector that looked at each segment alone would see fragments it cannot parse. Wireshark calls the fix **reassembly**: the TCP dissector holds a contiguous run of segments and hands the combined bytes to the higher-layer dissector once the message is complete. Two TCP preferences, under **Edit > Preferences > Protocols > TCP**, control it. ## Allow subdissector to reassemble TCP streams This preference is **on by default**. With it on: - a higher-layer dissector that finds a message incomplete asks TCP for more data, and TCP buffers segments until the message ends; - the decoded message appears on the frame that carries its **last** segment, and that frame's bytes pane gains a **Reassembled TCP** tab; - each earlier segment shows `[TCP PDU reassembled in N]` in the Info column and the generated field `tcp.reassembled_in`, pointing to that frame; - a display filter on a higher-layer field, such as `http.response`, matches only the frames where messages were completed, so it returns far fewer frames than there are segments. With it **off**, every segment is handed up on its own. HTTP bodies show as **Continuation** and TLS records as **Ignored Unknown Record**. The user guide suggests turning it off only to save memory and processing when you care about TCP sequence analysis alone. The same symptoms appear with it on when the capture started mid-connection or segments are missing or out of order. Higher layers have switches of their own that depend on this one, all on by default: **Reassemble HTTP headers spanning multiple TCP segments**, **Reassemble HTTP bodies spanning multiple TCP segments** and **Reassemble TLS records spanning multiple TCP segments**. ## Reassemble out-of-order segments This preference is **off by default** in Wireshark 4.6, and its own description says it needs the first one enabled; in the 4.6 source it also acts only while **Analyze TCP sequence numbers**, on by default, stays on. When Wireshark meets a gap while processing a capture in order, it assumes the missing bytes will turn up later, as a retransmission or a segment captured out of order, and buffers the new segments so they can join the same message. Its caveats come from that assumption: 1. If every segment arrived in order, it changes nothing. 2. If the **capture** dropped the segments for good, the message can never complete, and every following segment of that stream stays unreassembled. Turn the preference off to get a partial dissection instead. 3. For 802.11 monitor-mode captures, where frames are often lost to reception problems, the user guide recommends leaving it off. 4. When the missing data closes one message and starts another, Wireshark waits for all of it and, in the GUI or a two-pass tshark run, shows both messages on the frame with the last segment. Why segments arrive out of order, and how the analyser flags it, are TCP and Expert Info subjects; this preference only decides what reassembly does about it. ## What you see with each combination | Subdissector reassembly | Out-of-order reassembly | Capture complete and in order | Capture with reordering or a gap | |---|---|---|---| | Off | Ignored | Each segment decoded alone; Continuation, Ignored Unknown Record | Same | | On (default) | Off (default) | Message decoded on its last segment | Messages around the gap may fail to decode | | On | On | Message decoded on its last segment | Reordered data joined; a gap the capture never fills blocks the message | ## Setting them outside the GUI In the preferences file and on the command line the names are `tcp.desegment_tcp_streams` and `tcp.reassemble_out_of_order`. `tshark -o` overrides them for one run without saving anything, and `tshark -2` performs a two-pass analysis so reassembly frame dependencies are calculated correctly; two-pass mode cannot read a live capture or a pipe. ## What reassembly never changes - **Follow TCP Stream** shows the payload in sequence order whatever these preferences say. - The captured bytes are untouched; only the decode differs. - Missing data is still missing; reassembly can join what the capture holds, never invent what it lacks.

  • Why does the filter `http.response` return about 200 frames when the capture holds 3,000 segments of HTTP traffic?
    With subdissector reassembly on, each response is decoded once, on the frame carrying its last segment. The other segments are marked `[TCP PDU reassembled in N]` and carry no `http` fields, so a filter on an HTTP field matches only the completing frames. To keep the segments too, filter on `tcp.stream` instead.
  • When would you deliberately turn 'Allow subdissector to reassemble TCP streams' off?
    On a very large capture where you only need TCP sequence analysis, to save memory and processing, or to see what each individual segment carried. The cost is the higher-layer decode: HTTP bodies appear as Continuation and TLS records as Ignored Unknown Record, and fields that live in reassembled messages stop matching.

saying these in an interview costs you the question

  • Wireshark shows a reassembled HTTP response on the first segment of the message.
  • Reassemble out-of-order segments is on by default, so nothing needs changing.
  • Turning on out-of-order reassembly recovers data that the capture dropped.
  • Turning reassembly off breaks Follow TCP Stream for that connection.
  • Continuation in the Info column means the server sent a malformed HTTP response.