A Wireshark capture of a slow transfer shows TCP Previous segment not captured and TCP ACKed unseen segment entries; how do you tell capture loss from real network loss?
answer
- who else saw the missing bytes
- the receiver's ACK is the witness
- repaired gap versus silent gap
- Dropped counter and capture start
- where the capture point sits
basics
~20 sAsk whether the receiver got the missing bytes. A gap followed by duplicate ACKs and a retransmission is real loss; a gap the receiver simply ACKs past, flagged ACKed unseen segment and never resent, is loss at the capture point only.
solid answer
~50 s`tcp.analysis.lost_segment` (Previous segment not captured) only says the sequence jumped forward in the capture; `tcp.analysis.ack_lost_segment` (ACKed unseen segment) says the other side acknowledged bytes the capture never recorded. Both are Warns, and both summaries add 'common at capture start'. The receiver's behaviour separates the cases. If it sends duplicate ACKs and the hole is later filled by a segment flagged as a retransmission, the receiver never got the data: real loss upstream of the capture point. If its ACK jumps past the hole and nothing is resent, the receiver had the data and only the capture missed it. I confirm capture-side loss with the Dropped count in the status bar, by checking whether the gaps cluster at the start or hit every stream at the same instants, and by remembering a one-direction view hides half the evidence.
go deeper
Recall the two flag names and that 'not captured' describes the capture file, not necessarily the network.
Explain what each flag compares against the sequence state, and that duplicate ACKs plus a later retransmission mark data the receiver really did not get.
Demonstrate attributing loss to a side: read the receiver's ACKs, check Dropped, compare streams at the same instant, and state where the capture point sits before concluding.
Argue for capture placement and capture-path capacity as part of the investigation plan, since a report that cannot separate capture loss from network loss wastes another team's time.
## Two flags, two different claims Wireshark's TCP sequence analysis tracks, per direction, the **next expected sequence number**. Two flags describe a hole in that picture, and they claim different things: | Info prefix | Field | Set when | What it proves | |---|---|---|---| | `[TCP Previous segment not captured]` | `tcp.analysis.lost_segment` | a segment's sequence number is **greater** than the next expected one | some bytes before this segment are **not in the capture** | | `[TCP ACKed unseen segment]` | `tcp.analysis.ack_lost_segment` | an acknowledgment covers bytes **beyond** anything the capture saw from the other side | the receiver **has** bytes the capture never recorded | Both are filed at **Warn**, and both expert summaries end with *(common at capture start)*. Neither says the network lost anything. The first only says the capture has a hole; the second says the hole was not a hole for the receiver. ## The receiver is the witness TCP gives you an independent observer for free: the receiver acknowledges what it actually got. Read what it does after the gap. **Real loss** (the receiver never got the bytes): 1. A gap: the next data segment is flagged Previous segment not captured. 2. The receiver sends **duplicate ACKs** (`[TCP Dup ACK n#k]`) repeating the acknowledgment of the last byte before the gap, often with SACK blocks describing what arrived after it. 3. The missing range arrives later, flagged **Retransmission**, **Fast Retransmission** or, if it lands soon enough, **Out-Of-Order**. 4. Only then does the receiver's acknowledgment move past the gap. **Capture loss** (the receiver got the bytes, the capture did not): 1. The same gap appears in the data direction. 2. No duplicate ACKs follow: the receiver's next ACK simply covers the missing range, and Wireshark flags it **ACKed unseen segment**. 3. The missing range is **never retransmitted**, because nobody needed it. Why a sender retransmits and how duplicate ACKs are generated belong to TCP itself; here they are only the evidence. ## Where the capture point sits changes the picture The flags describe the capture point, not the path: - **Captured upstream of the loss** (near the sender): there is no gap at all. You see the original segment, then duplicate ACKs, then a retransmission of a segment the capture already holds. - **Captured downstream of the loss** (near the receiver): you see the gap, the duplicate ACKs and the repair, as above. - **Captured on a path that carries only one direction** (asymmetric routing, a one-way feed): ACK-based reasoning is impossible for the direction you cannot see, and ACKed unseen segment can fire on data that took the other path. So every conclusion should name its side: "the capture host missed these" or "the receiver never got these". ## Corroborating capture-side loss Before you report a lossy network, rule out the capture: - **The Dropped count.** During and after a live capture, the status bar shows *Dropped* when Wireshark could not capture every packet the capture host received. Most file formats do not record that count, so note it before you save the file. - **Capture start.** One Previous segment not captured on the first data packet of a long-lived stream usually means the capture started mid-transfer. - **Pattern across streams.** Gaps that hit many unrelated conversations at the same instants, with no duplicate ACKs, look like the capture path overflowing, not like congestion on one link. - **Upstream of the capture host.** A mirror or tap delivering less than the link carried can drop packets before Wireshark sees them, and the Dropped counter cannot know about that; the sensor-feed side of that problem is its own subject. ## A quick procedure 1. Open **Analyze > Expert Info**, hide Chat and Note, and read the counts of the two Warn entries. 2. Apply `tcp.analysis.ack_lost_segment` and open **Statistics > Conversations** with *Limit to display filter*, to see whether the flags are spread across every conversation or concentrated in one. 3. Pick one gap in the conversation that matters and follow the sequence numbers: duplicate ACKs and a later retransmission mean real loss; an ACK leaping the hole and no resend mean capture loss. 4. Write the conclusion with its side and its evidence, and re-capture closer to the endpoint or with a faster capture path if the capture itself was lossy. ## Why it matters A report that blames the WAN for 2% loss, when the analyst's laptop dropped those packets, sends a network team chasing nothing and leaves the real cause untouched. The receiver's acknowledgments are the cheapest proof available of which side lost the data.
- Gaps appear in every TCP stream of the capture at the same few seconds, with no duplicate ACKs anywhere. What is the likeliest cause?The capture path overflowed during a burst: the capture host or the feed delivering packets to it could not keep up, so all streams lost packets at once. Real congestion would show duplicate ACKs and retransmissions on the affected conversations. Check the Dropped count and the feed's capacity before blaming the network.
- Why can't you use ACKed unseen segment on a capture that sees only one direction of the traffic?The flag compares an ACK against data seen in the other direction. If that direction's data takes a path the capture point does not see, every ACK covers unseen bytes and the flag fires constantly. With one direction only, the receiver's behaviour cannot be read, so loss cannot be attributed to either side.
saying these in an interview costs you the question
- TCP Previous segment not captured means the network dropped that segment.
- ACKed unseen segment shows the receiver lost data and must ask for it again.
- A capture taken next to the sender will show every network loss as a gap.
- A zero Dropped count proves the capture saw every packet on the wire.
- A gap at the very start of a stream is always worth escalating as packet loss.