2026-06-02

Packet Loss PCAP Analysis: Retransmissions, Duplicate ACKs, and Where Packets Disappeared

How to use packet captures to diagnose packet loss, TCP retransmissions, duplicate ACKs, capture-point bias, and whether loss happened on the network or host.

packet loss pcap, tcp retransmission, duplicate ack, network troubleshooting, packet capture

Packet loss is one of the most searched network troubleshooting topics because the symptoms are broad: slow downloads, frozen video, failed uploads, bad VoIP quality, broken RTSP streams, TCP retransmissions, game lag, VPN instability, and HTTP timeouts. Users search for "packet loss pcap analysis", "TCP retransmission meaning", "duplicate ACK Wireshark", and "how to find packet loss in pcap" because they need proof, not guesses.

A packet capture can prove a lot, but only if you interpret it carefully. A retransmission in one capture does not automatically prove the network dropped a packet. It may prove that the capture point did not see a packet, the sender retransmitted because it did not receive an ACK, or the receiver saw out-of-order data.

PCAP Surgery is useful in this workflow because packet loss investigations often require trimming a large capture to one conversation, preserving timestamps, comparing capture points, and keeping sequence-number evidence intact.

What packet loss looks like in TCP

TCP tries to recover from loss. In packet captures, this can appear as:

  • Retransmissions
  • Fast retransmissions
  • Duplicate ACKs
  • Out-of-order packets
  • Selective ACK blocks
  • Gaps in sequence numbers
  • Long delays before data resumes
  • Reduced throughput after loss

The capture may label a packet as retransmission, but the label is an interpretation. The underlying evidence is sequence numbers, acknowledgments, timing, and direction.

Duplicate ACKs

A duplicate ACK means the receiver is acknowledging the same sequence number again. This usually happens because it received data beyond a missing segment and is still waiting for the missing bytes.

Example:

Sender -> Receiver: Seq 1000 Len 1000
Sender -> Receiver: Seq 2000 Len 1000
Sender -> Receiver: Seq 3000 Len 1000
Receiver -> Sender: ACK 2000
Receiver -> Sender: ACK 2000
Receiver -> Sender: ACK 2000
Sender -> Receiver: Retransmit Seq 2000 Len 1000

The repeated ACK tells the sender that the receiver is missing data starting at sequence 2000. After enough duplicate ACKs, the sender may retransmit quickly instead of waiting for a timeout.

Retransmission timeout

If the sender does not receive enough feedback, it may wait for a retransmission timeout. This creates a visible pause. The application may experience that pause as slow loading, frozen upload, or delayed response.

Timeout-based recovery is usually more painful than fast retransmission because the sender waits longer before retrying.

When investigating, measure:

  • Time between original packet and retransmission.
  • Whether duplicate ACKs were present.
  • Whether SACK information identified missing ranges.
  • Whether the retransmission succeeded.
  • Whether loss repeated at regular intervals.

Capture point bias

The most important question in packet loss analysis is: where was the capture taken?

If you capture on the sender and see the original packet leave, you know the sender tried to send it. If you capture on the receiver and do not see it arrive, you know it disappeared somewhere between the two capture points. If you capture only in the middle, you need to be careful.

A single capture often cannot prove the exact physical point of loss. Two synchronized captures, one near each endpoint, are much stronger.

Example:

  • Sender capture sees packet A.
  • Receiver capture does not see packet A.
  • Receiver later sends duplicate ACKs.
  • Sender retransmits packet A.

That strongly suggests loss between sender and receiver.

But if sender capture does not show packet A, the problem may be sender-side, capture filtering, offload, or capture loss.

Capture loss vs network loss

Packet captures can drop packets too. A busy host, overloaded capture process, or insufficient buffer can miss packets. That can create false gaps.

Signs of capture loss include:

  • Capture tool reports dropped packets.
  • Missing packets do not align with TCP behavior.
  • Multiple conversations show impossible gaps at the same moment.
  • High traffic rate exceeds capture capacity.
  • Host CPU or disk is overloaded during capture.

Do not confuse "not present in the pcap" with "lost on the network" until capture quality is considered.

TCP SACK evidence

Selective ACK, or SACK, helps identify which data ranges the receiver has received beyond the missing gap. SACK blocks can make packet loss analysis much clearer.

If the receiver ACKs sequence 2000 but includes SACK blocks for 3000-5000, it means the receiver has later data but is missing the earlier segment. That is strong evidence of a missing segment, reordering, or capture artifact.

SACK helps distinguish simple loss from out-of-order delivery.

Out-of-order is not always loss

Out-of-order packets can happen when network paths reorder traffic. TCP can recover if the missing earlier segment arrives soon. But if out-of-order delivery triggers duplicate ACKs and retransmissions, it may reduce performance even without true packet loss.

When analyzing:

  • Check whether the missing segment arrives later.
  • Compare the delay between out-of-order arrival and missing segment arrival.
  • Look for retransmission that arrives after the original delayed packet.
  • Determine whether reordering is occasional or constant.

Some networks, VPNs, tunnels, and load-balanced paths make reordering more likely.

UDP packet loss

UDP does not retransmit at the transport layer. Packet loss in RTP, DNS, QUIC, gaming, or custom UDP protocols must be inferred from protocol-specific sequence numbers, timestamps, request/response gaps, or application behavior.

For RTP video, look at RTP sequence number gaps. For DNS, look at queries without responses. For QUIC, inspect observable packet numbers only when available and account for encryption limits. For custom telemetry, look for application-level counters or timestamps.

TCP retransmission logic does not apply to UDP. That is why protocol context matters.

Checklist for packet loss PCAP analysis

Use this process:

  1. Identify the affected conversation.
  2. Determine whether the traffic is TCP, UDP, or another protocol.
  3. For TCP, inspect sequence numbers, ACKs, duplicate ACKs, retransmissions, and SACK.
  4. For UDP, inspect protocol-specific sequence numbers or missing responses.
  5. Identify capture point and direction.
  6. Check whether the capture tool dropped packets.
  7. Measure loss timing and recurrence.
  8. Compare with application logs and network device counters.
  9. Use two capture points if exact loss location matters.
  10. Trim and preserve the evidence before sharing.

Why edited capture files need care

When you trim a capture for analysis, preserve packet order, timestamps, and the affected conversation. Do not accidentally remove the original packet, duplicate ACKs, or retransmission that prove the behavior.

PCAP Surgery is designed around that principle: make captures smaller and safer to share while keeping the evidence needed to understand what happened.

Final diagnosis

Packet loss analysis is not just looking for red retransmission labels. It is a disciplined sequence-number investigation. The correct answer depends on capture point, direction, protocol, timing, SACK, duplicate ACKs, and capture quality.

PCAP Surgery helps keep that evidence intact so the final trace explains whether packets were lost, delayed, reordered, hidden by capture limitations, or retransmitted because the receiver never acknowledged them.