Analyze TCP streams and UDP streams in Wireshark for packet loss, retransmissions, and jitter

Tested With: Wireshark 4.x
Wireshark is one of the most useful tools for diagnosing slow applications, packet loss, TCP retransmissions, high latency, unstable UDP traffic, DNS delays, and poor voice or video quality.
The most important concept is that TCP and UDP cannot be analyzed in exactly the same way.
TCP provides sequence numbers, acknowledgments, retransmissions, flow control, and congestion-control mechanisms. Wireshark can use this information to identify many TCP conditions directly.
UDP does not provide TCP-style reliability. With UDP, loss and timing problems usually need to be identified using the application protocol, packet timing, sequence information, or request-and-response behavior.
A useful troubleshooting mindset is:
User symptom → affected flow → first abnormal event → packet evidence → probable cause → corrective action → verification

—

TCP and UDP Troubleshooting Fundamentals

Before applying filters, understand what Wireshark is actually observing.

How TCP Handles Missing Data

TCP is designed to provide reliable delivery.
Imagine a sender transmitting:
Segment 1 → Segment 2 → Segment 3 → Segment 4
If Segment 3 disappears somewhere between the sender and receiver, TCP has mechanisms that help detect the missing data and recover from the problem.
The sender may eventually transmit Segment 3 again.
Wireshark can therefore identify conditions such as:

• Retransmissions
• Fast retransmissions
• Duplicate ACKs
• Out-of-order packets
• Sequence gaps
• Spurious retransmissions
• RTT changes
• Receiver-window conditions
• Bytes in flight

How UDP Handles Missing Data

UDP behaves differently.
UDP itself:

• Does not acknowledge received packets
• Does not retransmit missing packets
• Does not guarantee delivery
• Does not guarantee packet order
• Does not provide TCP-style flow control

If a UDP packet disappears, UDP itself does not request it again.
Applications running over UDP may provide their own mechanisms.
Examples include:

• RTP sequence numbers
• DNS transaction IDs and retries
• Application counters
• Custom telemetry sequence numbers
• Application-level acknowledgments

Packet Loss, Retransmission, Latency and Jitter

These terms describe different conditions.
Packet Loss
A packet expected at a particular destination or observation point was not received or observed.
Possible causes include:

• Congestion
• Interface errors
• Wireless interference
• Firewall or ACL drops
• Traffic policing
• Overloaded devices
• Routing problems
• Faulty links
• MTU problems
• Capture loss

TCP Retransmission
TCP transmitted data again because the original transmission was considered missing or otherwise required retransmission.
A retransmission is usually a recovery action or symptom, not necessarily the root cause.
Latency
Latency describes delay.
In TCP analysis, round-trip time helps show how long it takes transmitted data to be acknowledged.
Jitter
Jitter describes variation in packet timing.
For example:
Expected
20 ms → 20 ms → 20 ms → 20 ms
Observed
20 ms → 22 ms → 65 ms → 8 ms
The average delay may not look severe, but large variations can cause problems for real-time applications.

—

Preparing a Reliable Packet Capture

Good packet analysis starts with a good capture.

Choose the Correct Capture Point

Whenever possible, capture close to the device experiencing the problem.
For example, a client-side capture can reveal:

• What the client transmitted
• What the client received
• How long responses took
• Whether TCP recovery occurred
• Whether DNS requests were retried
• Which direction appears affected

For difficult problems, simultaneous captures at multiple locations provide much stronger evidence.

Identify the Linux Interface

ip -br address

Check which interface Linux will use toward a destination:

ip route get 1.1.1.1

The output should identify the selected route and outgoing interface.

Check NIC Offloading

GRO, GSO, LRO, and TSO can influence what packets look like when capturing directly on an endpoint.
Check the current configuration:

sudo ethtool -k eth0

For a controlled troubleshooting capture, selected offloads may temporarily be disabled when appropriate:

sudo ethtool -K eth0 gro off lro off gso off tso off

Restore the required settings afterward:

sudo ethtool -K eth0 gro on lro on gso on tso on

Synchronize Time

Accurate clocks become particularly important when comparing:

• Client captures
• Server captures
• Firewall logs
• Load-balancer logs
• Application logs
• Monitoring systems

Check Linux time synchronization:

timedatectl status

Use a Ring Buffer

Intermittent problems may require longer captures.
Instead of creating one extremely large capture, use rotating files:

sudo dumpcap -i eth0 -b filesize:200000 -b files:5 -w rolling.pcapng

Create Safe Practice Traffic

The best way to learn retransmission analysis is in an isolated laboratory.

TCP packet-loss test
Start iperf3 on the server:

iperf3 -s

Start a client-side TCP capture:

sudo tcpdump -i eth0 -w tcp_loss.pcapng tcp

Introduce 5% random packet loss:

sudo tc qdisc add dev eth0 root netem loss 5%

Generate TCP traffic:

iperf3 -c SERVER_IP -t 30

Remove the impairment:

sudo tc qdisc del dev eth0 root

The capture should contain TCP recovery behavior such as retransmissions and potentially duplicate ACKs, depending on which packets were lost and where the capture was taken.

UDP timing test
Capture UDP:

sudo tcpdump -i eth0 -w udp_jitter.pcapng udp

Introduce variable delay:

sudo tc qdisc add dev eth0 root netem delay 30ms 10ms

Generate UDP traffic:

iperf3 -c SERVER_IP -u -b 1M -t 30

Remove the impairment:

sudo tc qdisc del dev eth0 root

—

TCP Analysis in Wireshark

The objective of TCP troubleshooting is not simply to count retransmissions.
Use this sequence:
What happened → when it happened → which direction → how TCP recovered → application impact

Isolate One TCP Stream

Start with:

tcp

Select a packet belonging to the connection of interest and use:
Follow → TCP Stream
Wireshark can then isolate the selected conversation.
A typical stream filter looks like:

tcp.stream eq 5

Add Useful TCP Information

Useful TCP fields include:

• tcp.stream
• tcp.len
• tcp.analysis.ack_rtt
• tcp.analysis.bytes_in_flight

Packet delta-time information can also help identify stalls.

Find Important TCP Analysis Events

Use:

tcp.analysis.retransmission or
tcp.analysis.fast_retransmission or
tcp.analysis.spurious_retransmission or
tcp.analysis.lost_segment or
tcp.analysis.duplicate_ack or
tcp.analysis.out_of_order

For retransmission-focused troubleshooting:

tcp.analysis.retransmission or
tcp.analysis.fast_retransmission or
tcp.analysis.spurious_retransmission

Understand the Main TCP Indicators

Retransmission
Wireshark believes TCP data has been transmitted again.
Finding a retransmission should trigger further investigation.
Check:

• What happened immediately before it?
• Was there a sequence gap?
• Were duplicate ACKs present?
• Did RTT increase?
• Did throughput decrease?
• Which direction was affected?

Fast Retransmission
TCP appears to have retransmitted data based on loss indications without waiting for the normal retransmission timeout.
Duplicate ACK
The receiver repeats an acknowledgment value.
Several duplicate ACKs may indicate that the receiver is waiting for missing sequence data.
Out-of-Order
Packets arrived in a different order from what Wireshark expected.
Possible explanations include:

• Network reordering
• Parallel network paths
• Load balancing
• Capture behavior
• Packet loss followed by later arrival

Understand Sequence Gaps

Imagine Wireshark observes:
Segment 1000
Segment 2000
Segment 4000
Expected data around sequence 3000 was not observed.
Possible explanations include:

• Network packet loss
• Capture loss
• Packet reordering
• Different forwarding behavior relative to the capture point

Use Expert Information

Open:
Analyze → Expert Information
Expert Information can help identify:

• Retransmissions
• Duplicate ACKs
• TCP resets
• Sequence anomalies
• Protocol warnings
• Malformed traffic

Read the Sequence and ACK Story

A common TCP recovery sequence looks like this:

1. Sender transmits data.
2. One segment does not arrive as expected.
3. Receiver acknowledges the last contiguous data.
4. Duplicate ACK or SACK information reveals a gap.
5. Sender retransmits missing data.
6. Receiver acknowledges additional data.
7. Throughput continues.

Use TCP Stream Graphs

Open:
Statistics → TCP Stream Graphs
Useful views include:

• Time Sequence
• Throughput
• Round Trip Time
• Window Scaling

Time Sequence
Use this graph to see how TCP sequence numbers progress over time.
Stalls or repeated sequence regions can help visualize recovery events.
Round Trip Time
Look for:

• Stable RTT
• Sudden RTT spikes
• Gradual RTT increases
• Repeated periods of high latency

Throughput
Compare throughput reductions against:

• Retransmissions
• RTT increases
• Window restrictions
• Application pauses

The important question is:
Did the TCP event actually affect the user’s application?

Check TCP Window Problems

Use:

tcp.analysis.window_full or tcp.analysis.zero_window

A TCP Zero Window generally indicates that the receiver is advertising no available receive-window space.
Possible causes include:

• Slow application processing
• Receive-buffer pressure
• Resource exhaustion
• Receiver-side bottlenecks

Distinguish Loss, Reordering and Capture Problems

Pattern suggesting packet loss

1. Sequence gap appears.
2. Duplicate ACK or SACK evidence follows.
3. Missing data is retransmitted.
4. ACK progression resumes.
5. Application throughput or timing is affected.

Pattern suggesting reordering

1. Packet arrives outside expected sequence.
2. Missing sequence data appears shortly afterward.
3. Sequence space becomes complete.
4. No significant recovery event follows.

Pattern suggesting capture problems
Capture loss becomes more likely on:

• Busy servers
• High-speed interfaces
• Oversubscribed SPAN ports
• Virtualized environments
• Systems with inadequate capture buffers

—

UDP, RTP and DNS Analysis in Wireshark

UDP troubleshooting begins by identifying the application protocol.
Examples include:

• RTP
• DNS
• QUIC
• DHCP
• SNMP
• Syslog
• Gaming protocols
• Telemetry
• Proprietary applications

Analyze RTP Voice and Video

For RTP traffic, open:
Telephony → RTP → RTP Streams
Select the relevant RTP stream and analyze it.
Wireshark can provide information such as:

• Packet count
• Lost packets
• Sequence errors
• Maximum delta
• Maximum jitter
• Mean jitter
• Maximum skew
• Duration

Understand RTP Packet Loss

RTP contains sequence numbers.
For example:
1001
1002
1003
1005
1006
Sequence 1004 was expected but not observed.

Understand RTP Jitter

Wireshark RTP analysis can show variation in packet timing.
When evaluating jitter, consider:

• Codec
• Packetization interval
• Jitter-buffer behavior
• Network design
• Loss pattern
• Burst duration
• Application tolerance

Compare Both RTP Directions

Always examine both directions.
For example:
User A → User B: Healthy
User B → User A: High jitter and packet loss
This can explain why only one participant reports poor audio.

Analyze Generic UDP

Filter one flow:

udp and ip.addr == PEER_IP and udp.port == PORT

Determine whether the application provides:

• Sequence numbers
• Timestamps
• Transaction IDs
• Counters
• Request/response indicators
• Application acknowledgments

Analyze DNS Timeouts and Retries

Filter DNS:

dns

For a particular DNS server:

dns and ip.addr == DNS_SERVER_IP

Useful fields include:

• dns.id
• dns.flags.response
• dns.qry.name
• dns.flags.truncated

@@SGLABEL_Example@@
The client sends:
Query → example.com
No response is observed.
After a delay:
Query → example.com
appears again.

Check DNS Truncation

Use:

dns.flags.truncated == 1

A truncated DNS response is not automatically evidence of packet loss.
It may result in another transport behavior such as TCP fallback.

Investigate MTU and Fragmentation

For IPv4 ICMP Fragmentation Needed:

icmp.type == 3 and icmp.code == 4

For IPv4 fragments:

ip.flags.mf == 1 or ip.frag_offset > 0

Investigate Wi-Fi Retries

With an appropriate IEEE 802.11 capture:

wlan.fc.retry == 1

—

Practical Troubleshooting Workflow

Instead of randomly searching packets, use a repeatable process.

Step 1 — Define the User Symptom

Start with what the user actually experiences.
Examples:

• Slow download
• Application freeze
• Connection timeout
• Choppy voice
• Video buffering
• DNS delay
• Connection reset

Do not begin with the assumption:
There must be packet loss.

Step 2 — Identify the Protocol

Determine whether the affected application uses:

• TCP
• UDP
• RTP
• DNS
• QUIC
• Another protocol

Step 3 — Isolate the Conversation

Use the most appropriate identifier:

• IP address
• Port
• TCP stream
• UDP conversation
• RTP stream
• DNS server
• Application-specific field

Step 4 — Establish Normal Behavior

Understand what should normally happen before deciding something is abnormal.

Step 5 — Find the First Abnormal Event

The first abnormal packet is often more valuable than the hundred retransmissions that follow it.

Step 6 — Look Immediately Before the Failure

Ask:

• Did RTT increase?
• Did a sequence gap appear?
• Did acknowledgments stop progressing?
• Did a DNS query receive no response?
• Did RTP sequence numbers jump?
• Did an ICMP error arrive?

Step 7 — Correlate Evidence

Combine multiple indicators:

• TCP sequence numbers
• ACKs
• SACK information
• RTT
• Retransmissions
• Receiver windows
• Application response time
• RTP sequence numbers
• RTP jitter
• DNS retries
• ICMP errors

Step 8 — Check Both Directions

Network problems can be asymmetric.
A healthy:
Client → Server
path does not guarantee a healthy:
Server → Client
path.

Step 9 — Compare Multiple Capture Points

This is one of the strongest methods for locating packet loss.

Step 10 — Verify the Fix

After making a change:

1. Reproduce the test.
2. Capture traffic again.
3. Compare the new capture with the original.
4. Confirm the packet behavior improved.
5. Confirm the user symptom disappeared.

Practical Scenario — Slow TCP Download

Check retransmissions

tcp.analysis.retransmission or tcp.analysis.fast_retransmission

Check RTT
Use:
Statistics → TCP Stream Graphs → Round Trip Time
Check receiver-window conditions

tcp.analysis.window_full or tcp.analysis.zero_window

Correlate
Determine whether throughput reductions correspond with:

• Retransmissions
• RTT increases
• Window restrictions
• Application pauses

The analysis should help determine whether the slowdown correlates with packet recovery, increased delay, receiver flow control, application behavior, or another condition.

Practical Scenario — Choppy VoIP

Open:
Telephony → RTP → RTP Streams
Analyze both directions.
Check:

• Lost packets
• Sequence errors
• Jitter
• Delta
• Skew
• Timing of problem bursts

Practical Scenario — Intermittently Slow DNS

Use:

dns and ip.addr == DNS_SERVER_IP

Compare:

• Query timestamp
• Response timestamp
• Repeated requests
• Transaction IDs
• Query names
• Truncated responses
• ICMP errors

Where possible, capture near both the client and DNS server.

Quick Wireshark Filters

TCP retransmissions

tcp.analysis.retransmission or tcp.analysis.fast_retransmission

Spurious retransmissions

tcp.analysis.spurious_retransmission

Duplicate ACKs

tcp.analysis.duplicate_ack

Out-of-order TCP

tcp.analysis.out_of_order

TCP window problems

tcp.analysis.window_full or tcp.analysis.zero_window

Specific TCP stream

tcp.stream eq STREAM_NUMBER

RTP

rtp

DNS

dns

DNS truncation

dns.flags.truncated == 1

IPv4 Fragmentation Needed

icmp.type == 3 and icmp.code == 4

IPv4 fragments

ip.flags.mf == 1 or ip.frag_offset > 0

Wi-Fi retry

wlan.fc.retry == 1

—

Common Problems and FAQ

Assuming Every Retransmission Means Congestion

Retransmissions can occur for different reasons.
Investigate:

• Sequence numbers
• ACK behavior
• RTT
• Reordering
• Capture location
• Capture loss
• Application behavior

Assuming Out-of-Order Means Packet Loss

Out-of-order packets and packet loss are different conditions.
Reordering may occur without actual packet loss.

Assuming a Missing Packet Proves a Network Drop

The capture mechanism itself may have missed the packet.
This is especially important when analyzing:

• High-speed links
• Busy servers
• SPAN ports
• Virtual systems
• Large captures

Treating Expert Information as Root Cause

Expert Information identifies conditions worth investigating.
It does not replace packet-level analysis.

Looking at Only One Direction

Many problems are asymmetric.
Always examine both traffic directions.

Looking Only at Average Values

Short bursts of severe packet loss or jitter can affect users even when the overall average appears acceptable.

Does a TCP Retransmission Prove Packet Loss?

No.
It provides evidence that TCP considered retransmission necessary, but sequence numbers, ACK behavior, timing, capture quality, and other evidence should be examined before identifying the root cause.

Does a Duplicate ACK Always Mean Packet Loss?

No.
Duplicate ACKs can help reveal TCP sequence behavior but must be interpreted within the complete stream.

Can Wireshark Calculate UDP Jitter?

For supported RTP streams, Wireshark provides dedicated timing and jitter analysis.
For generic UDP, analysis normally depends on packet timing and application-specific information.

Is High RTT the Same as Packet Loss?

No.
RTT measures delay.
Packet loss and high RTT may occur together during congestion, but they represent different network conditions.

Does TCP Zero Window Mean Packet Loss?

No.
A Zero Window normally indicates receiver-side flow control.
The receiver is telling the sender that it currently cannot accept additional TCP data.

Can One Packet Capture Identify the Exact Device Dropping Traffic?

Usually not.
Multiple synchronized capture points provide much stronger evidence for locating where traffic disappears.

Should Every Wireshark Warning Be Fixed?

No.
Wireshark analysis flags must be interpreted according to the protocol, application, capture location, and expected behavior.
—

Summary

Wireshark becomes much easier to understand when packet troubleshooting is treated as a story rather than a collection of colored packets.
For TCP:
Data → Sequence Number → ACK → Gap → Recovery → RTT → Performance Impact
For RTP:
Sequence → Missing Packet → Timing → Jitter → User Impact
For DNS:
Query → Response → Delay → Retry → Compare Capture Points
The most important lessons are:

• TCP and UDP require different troubleshooting approaches.
• TCP retransmissions are recovery behavior, not automatically the root cause.
• Duplicate ACKs, retransmissions, sequence gaps, RTT, and receiver-window behavior should be correlated.
• UDP packet loss can be difficult to prove unless the application provides sequence or transaction information.
• RTP provides useful sequence and timing information for media troubleshooting.
• DNS retries show that a transaction did not complete as expected but do not by themselves identify where traffic disappeared.
• Out-of-order traffic is not automatically packet loss.
• Capture loss must always be considered.
• Analyze both directions.
• Multiple capture points provide stronger evidence than a single capture.
• The first abnormal event is often more useful than the symptoms that follow.
• Always capture again after making a change.

The objective is not simply to find a packet marked Retransmission.
The objective is to determine:
What happened → why it happened → where it happened → how it affected the application → whether the corrective action solved the problem
—

Useful Links and References

SanchitGurukul Static Resources

Official External References