All Products
Search

This Product

    :Troubleshooting tcpdump and Wireshark packet capture

    Document Center

    :Troubleshooting tcpdump and Wireshark packet capture

    Last Updated:Jun 17, 2026

    Diagnose common tcpdump and Wireshark messages such as packet loss, retransmission, and window issues.

    Background

    tcpdump and Wireshark are network protocol analysis tools. Wireshark supports Linux, Windows, and macOS. Cloud Linux instances typically lack a GUI, so use tcpdump for packet capture on these instances. See Capture network packets for installation and usage instructions.

    Common tcpdump messages

    [Packet size limited during capture]

    Symptom: The full packet is 171 bytes, but only the first 96 bytes are captured.

    No.  Time      Source  Destination  Protocol  Info
1    0.000000  Client  Server       TCP       48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE
2    0.001482  Server  Client       TCP       443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1
3    0.001501  Client  Server       TCP       48113-443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=4157
4    0.009432  Client  Server       SSL       [Packet size limited during capture]
5    0.010923  Server  Client       TCP       443-48113 [ACK] Seq=1 Ack=106 Win=5792 Len=0 TSval=43

Frame 4: 171 bytes on wire (1368 bits), 96 bytes captured (768 bits)

    Possible cause: The full packet was not captured due to default capture tool settings.

    Solution: Some operating systems limit tcpdump to the first 96 bytes per frame by default. Use the -s parameter to specify the capture size:

    sudo tcpdump -i eth0 -s 1000 -w tcpdump.cap

    Common Wireshark messages

    [TCP Previous segment not captured]

    Symptom: Packet loss or missed packets occur during the packet capture. 

    No.  Time      Source  Destination  Protocol  Info
1    0.000000  Client  Server       TCP       48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE
2    0.001482  Server  Client       TCP       443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1
3    0.001501  Client  Server       TCP       48113-443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=4157
4    0.009432  Client  Server       SSL       [Packet size limited during capture]
5    0.010923  Server  Client       TCP       443-48113 [ACK] Seq=1 Ack=106 Win=5792 Len=0
6    0.011691  Client  Server       SSL       [TCP Previous segment not captured]

Transmission Control Protocol, Src Port: 443, Dst Port: 48113, Seq: 1449, Ack: 106, Len: 667

    Possible cause: The previous TCP segment was not captured, leaving an incomplete data segment. This is typically caused by packet loss or the capture tool missing packets.

    Solution: Analyze the capture results to determine the specific situation.

    Note

    In TCP transmission, data segments from the same host should be continuous. The Seq of each subsequent segment should equal the previous segment's Seq plus its payload length (Seq + Len - TCP header length). The receiver's Ack equals the sender's Seq plus payload length, indicating the next expected byte (except during three-way or four-way handshakes). If a subsequent segment's Seq exceeds the previous Seq plus payload length with no intermediate segment observed, the following situations may exist:

    • Missed packet capture (TCP Previous segment not captured): If a subsequent Ack covers the uncaptured Seq range (e.g., the sender sends Seq=1000 and Seq=2000, and the receiver returns Ack=2000), the receiver acknowledged the intermediate data, but the capture tool missed it.

    • Packet loss: If a subsequent Ack does not cover the uncaptured Seq range (e.g., the sender sends Seq=1000 and Seq=2000, and the receiver returns Ack=1000), the receiver has not acknowledged the intermediate data, indicating possible packet loss.

    • Network segments may arrive out of order. The receiver repeatedly acknowledges the last contiguous Ack via Seq until the missing segment arrives.

    Out-of-order and window processing logic:

    • If the segment Seq exceeds the receive window (Window), the receiver discards it. Recovery relies on timeout or fast retransmission.

    • If the segment Seq exceeds the receive window (Window), the receiver discards it. Recovery relies on timeout or fast retransmission.

    [TCP ACKed unseen segment]

    Symptom: The message [TCP ACKed unseen segment] appears during packet capture. 

    No.  Time      Source  Destination  Protocol  Info
32   1.256720  Server  Client       TCP       [Continuation to #26] 445-2199 [ACK] Seq=6889 Ack=885 Win=65535 Len=1448
33   1.256729  Server  Client       TCP       2199-445 [ACK] Seq=885 Ack=8337 Len=2920 Len=0
34   1.256961  Client  Server       TCP       [TCP ACKed unseen segment] 2199-445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0
35   1.257191  Server  Client       TCP       [Continuation to #26] [TCP Previous segment not captured] 445-2199 [ACK] Seq=11233

    Possible cause: This message indicates that a packet was acknowledged, but the original packet was not seen in the capture. In the example, the packet in line 32 has a sequence number (Seq) of 6889 and a length (Len) of 1448. The sum is 8337 (6889 + 1448), so the next expected Seq from the server should be 8337. However, the packet in line 35 has a Seq of 11233. This means the segments between 8337 and 11232 were not captured. Only the subsequent acknowledgment was captured, while the preceding data packets were missed. The missing data should have appeared before line 34.

    Solution: This is one of the most common Wireshark messages. Analyze the capture results to determine the specific situation.

    [TCP Out-of-Order]

    Issue: The [TCP Out-of-Order] message appears during packet capture.

    No.   Time      Source  Destination  Protocol  Info
3360  5.007813  Server  Client       TCP       49454-8888 [ACK] Seq=2712622 Ack=2761 Win=32768
3361  5.007813  Client  Server       TCP       8888-49454 [ACK] Seq=2761 Ack=2639576 Win=2457
3362  5.007813  Server  Client       TCP       [TCP Out-of-Order] 49454-8888 [ACK] Seq=2685642
3363  5.007813  Client  Server       TCP       8888-49454 [ACK] Seq=2761 Ack=2664291 Win=2457

    Possible cause: Wireshark flags a packet as out-of-order when its Seq is smaller than the previous packet's Seq + Len. Small-span reordering (e.g., 2, 1, 3, 4, 5) has little impact. Large-span reordering (e.g., 2, 3, 4, 5, 1) triggers enough Dup ACK messages to cause fast retransmission.

    Solution: Occasional small-span reordering can be ignored. If large-span reordering occurs frequently, use tools such as MTR for further analysis, or check logs on intermediate devices such as switches and routers.

    [TCP Dup ACK]

    Issue: The [TCP Dup ACK] message appears during packet capture.

    No.  Time      Source  Destination  Protocol  Info
3    0.007813  Client  Server       TCP       [Continuation to #] 55448-445 [ACK] Ack=243 Len=888
4    0.007813  Client  Server       TCP       [TCP Previous segment not captured] 55448-445 [ACK]
5    0.007813  Server  Client       TCP       445-55448 [ACK] Seq=243 Ack=1 Win=65535
6    0.007813  Client  Server       TCP       445-55448 [ACK] Seq=243 Ack=1 Win=885
7    0.007813  Server  Client       TCP       [TCP Dup ACK] 8888-49454 Ack=1466 Win=1 Len=0
8    0.007813  Server  Client       TCP       [TCP Dup ACK] 8888-49454 Ack=1466 Win=1 Len=0
9    0.007813  Server  Client       TCP       [TCP Dup ACK] 8888-49454 [ACK] Seq=2185
10   0.007813  Server  Client       TCP       [TCP Dup ACK] 443-33448 [ACK] Seq=2185

    Possible cause: Duplicate ACKs occur when the receiver gets packets with Seq values greater than expected (due to out-of-order delivery or packet loss). The receiver responds with the expected Seq for each such packet, producing duplicate ACKs.

    Solution: If this occurs frequently, use tools such as MTR for further analysis, or check logs on intermediate devices such as switches and routers.

    [TCP Retransmission]

    Issue: The [TCP Retransmission] message appears during packet capture.

    Filter: tcp.seq == 1012852

No.   Time      Source  Destination  Protocol  Info
1053  0.804688  Client  Server       TCP       49454-8888 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=...
1225  0.937500  Client  Server       TCP       [TCP Retransmission] 49454-8888 [ACK] Seq=1012852 Ack...

    Possible cause: This message indicates that a packet was retransmitted. If a packet is lost and no subsequent packets arrive to trigger duplicate ACKs at the receiver, a fast retransmission does not occur. The sender must wait for the retransmission timer to expire and then perform a timeout retransmission. In the example, the client sent packet 1053 but did not receive an acknowledgment for it. After more than 100 ms, it retransmitted the data in packet 1225.

    Solution: If this occurs frequently, use tools such as MTR for further analysis, or check logs on intermediate devices such as switches and routers.

    Note

    TCP ensures reliable transmission by setting a timer when sending data. If no acknowledgment arrives before the timer expires, the data is retransmitted. RFC2988 defines the retransmission time calculation, which Linux still uses. See the RTT and RTO sections in the TCP-IP documentation for details.

    [TCP Fast Retransmission]

    Issue: The [TCP Fast Retransmission] message appears during packet capture.

    No.   Time      Source  Destination  Protocol  Info
1169  0.828125  Server  Client       TCP       49454-8888 [ACK] Seq=1098048 Ack=1105 Win=32768 Len=1448
...
1171  0.828125  Client  Server       TCP       8888-49454 [ACK] Seq=2761 Ack=991851 Win=2457 Len=0
...
1174  0.867188  Client  Server       TCP       [TCP Dup ACK 1171#1] 8888-49454 [ACK] Seq=1105 Ack=991851
1175  0.867188  Client  Server       TCP       [TCP Dup ACK 1171#2] 8888-49454 [ACK] Seq=1105 Ack=991851
1176  0.867188  Client  Server       TCP       [TCP Dup ACK 1171#3] 8888-49454 [ACK] Seq=1105 Ack=991851
1177  0.867188  Server  Client       TCP       [TCP Fast Retransmission] 49454-8888 [ACK] Seq=991851

    Possible cause: This message indicates a fast retransmission. When a sender receives three or more duplicate ACKs, it assumes the original packet was lost and immediately retransmits it without waiting for the retransmission timer to expire. In the example, after receiving three duplicate ACKs, the server retransmits the data with Seq 991851 in packet 1177.

    Solution: If this occurs frequently, use tools such as MTR for further analysis, or check logs on intermediate devices such as switches and routers.

    Note

    Fast retransmission provides an alternative to timeout-based loss detection. When the receiver sends three consecutive duplicate ACKs, the sender retransmits the unacknowledged segment without waiting for the retransmission timer to expire.

    [TCP zerowindow]

    Issue: The [TCP zerowindow] message appears during packet capture.

    No.   Time      Source  Destination  Protocol  Info
3258  3.140625  Server  Client       TCP       Seq=467 Ack=11928601 Win=15872 Len=0
3259  3.140625  Server  Client       TCP       Seq=467 Ack=11931449 Win=13025 Len=0
3260  3.140625  Server  Client       TCP       Seq=467 Ack=11934174 Win=10300 Len=0
3261  3.140625  Server  Client       TCP       Seq=467 Ack=11940137 Win=3517 Len=0
3262  3.140625  Server  Client       TCP       [TCP ZeroWindow] Seq=467 Ack=11941327 Win=0 Len=0
3263  3.140625  Server  Client       TCP       [TCP ZeroWindow] 8888-62758 Seq=467 Ack=... Win=0
3265  3.140625  Server  Client       TCP       [TCP ZeroWindow] 8888-62758 [ACK] Win=0
3267  3.167969  Server  Client       TCP       [TCP ZeroWindow] 8888-62758 [PSH, ACK] Seq=7743 Win=0

    Possible cause: This message indicates that the receiver's receive window is zero. This means its buffer is full and it cannot accept more data. The Win= field in a TCP header advertises the available buffer space. A value of Win=0 signals the peer to stop sending data, as shown in the example.

    Solution: This may indicate insufficient processing capacity at the receiver or insufficient network bandwidth. Further analysis is needed.

    [TCP window Full]

    Symptom: The message [TCP Window Full] appears during packet capture. 

    No.  Time        Source       Destination  Protocol  Info
71   3.392855    middle east  britain      TCP       [TCP Window Full] 64560-12345 [ACK] Seq=202344 Ack=1
72   3.393142    middle east  britain      TCP       12345-64560 [ACK] Seq=1 Ack=142521 Win=5792 Len=0
73   3.395832    middle east  britain      TCP       [TCP Window Full] 64560-12345 [ACK]
74   3.396350    middle east  britain      TCP       12345-64560 [ACK]
75   3.407549    middle east  britain      TCP       [TCP Window Full]
76   4.002180    britain      middle east  TCP       ...
78   4.004231    britain      middle east  TCP       64560-12345 Seq=1 Ack=51089

[Bytes in flight: 65535]
[iRTT: 0.040960000 seconds]

    Possible cause: This message indicates that the sender's send window is full. This means the sender has sent enough data to fill the receiver's advertised window and must stop sending data.

    Solution: This may indicate insufficient processing capacity at the receiver or insufficient network bandwidth. Further analysis is needed.

    Note

    Bytes in flight equals the peer's receive window, meaning the number of sent bytes minus the most recently acknowledged bytes equals the outstanding bytes (Seq + Len = Ack, where Ack is the latest acknowledgment). The following two fields indicate that transmission has paused and warrant attention.

    Bytes in flight equals the receiver's window, meaning the sender's outstanding bytes fill the entire window (Seq + Len = Ack, where Ack is the latest acknowledgment). The following two fields indicate that transmission has paused and warrant high attention.

    [TCP segment of a reassembled PDU]

    Issue: The [TCP segment of a reassembled PDU] message appears during packet capture.

    No.  Time      Source  Destination  Protocol  Info                                              Length
86   5.011522  Client  Server       SMB       Read AndX Request, FID: 0x00a4, 14215 bytes        ...
87   5.014424  Server  Client       SMB       Read AndX Response, FID: 0x004a, 14215 bytes       ...
88   5.014024  Client  Server       TCP       TCP segment of a reassembled PDU
89   5.014028  Client  Server       TCP       TCP segment of a reassembled PDU
90   5.014028  Server  Client       TCP       TCP segment of a reassembled PDU
91   5.014028  Server  Client       TCP       TCP segment of a reassembled PDU
...

Frame 86: 1311 bytes on wire (10504 bits), 1311 bytes captured (10504 bits)

    Possible cause: Wireshark can virtually group TCP packets belonging to the same application-layer PDU.

    Solution: Go to Edit > Preferences > Protocol > TCP, and verify that "Allow sub dissector to reassemble TCP streams" is enabled. The ACK confirmation packet numbers should match.

    [Continuation to #X]

    Issue: The [Continuation to #X] message appears during packet capture.

    No.  Time      Source  Destination  Protocol  Info
38   5.011522  Client  Server       SMB       Read AndX Request, FID: 0x00a4, 14215 bytes at offset D
39   5.014424  Server  Client       SMB       Read AndX Response, FID: 0x004a, 14215 bytes
40   5.014019  Server  Client       TCP       445-2212 [ACK] Seq=1331 Ack=1913 Win=65535 Len=1448
41   5.014024  Server  Client       TCP       [Continuation to #39] 445-2212 [ACK] Len=1448
42   5.014028  Server  Client       TCP       [Continuation to #39] 445-2212 [ACK] Len=1448
43   5.014028  Server  Client       TCP       [Continuation to #97] 445-2212 [ACK]
44   5.014032  Server  Client       TCP       [Continuation to #97] 445-2212 [ACK]
45   5.014047  Server  Client       TCP       [Continuation to #97] 445-2212 [ACK]

    Possible cause: "Allow sub dissector to reassemble TCP streams" is disabled.

    Solution: Go to Edit > Preferences > Protocol > TCP, and enable "Allow sub dissector to reassemble TCP streams".

    Time-to-live exceeded (Fragment reassembly time exceeded)

    Symptom: The message "Time-to-live exceeded (Fragment reassembly time exceeded)" appears during packet capture. 

    No.   Time       Source          Destination     Protocol  Info
...   ...        Beijing         Shanghai        ICMP      Time-to-live exceeded (Fragment reassembly time exceeded)
...   ...        Beijing         Shanghai        ICMP      Time-to-live exceeded (Fragment reassembly time exceeded)
...

    Possible cause: This ICMP message indicates that the time-to-live (TTL) expired because the time limit for reassembling fragmented packets was exceeded. This happens when a host receives some fragments of a packet but fails to receive all of them within a certain time. For example, if packets sent from Shanghai to Beijing are fragmented and some fragments are lost in transit, the destination host in Beijing cannot reassemble the original packet and sends this ICMP error message back to the source.

    Solution: If this persists, check routing tables, use MTR to troubleshoot network loops, adjust the initial TTL value or MTU, or optimize network bandwidth.

    References