Find MTU errors and distinguish them from ordinary packet loss

Start with explicit ICMP size errors, then check whether the sender reduces its packet size and the transfer resumes. If those errors are missing, look for a repeatable pattern: small packets pass, larger packets fail, and sending smaller packets restores progress. Retransmissions alone do not identify an MTU problem.

The path MTU is the smallest link MTU along a particular path—not necessarily the MTU configured on either endpoint. In IPv4, a router cannot forward an oversized packet with Don’t Fragment (DF) set; it drops the packet and returns a fragmentation-needed error. IPv6 routers do not fragment packets and use Packet Too Big errors instead. These are the signals used by classical Path MTU Discovery (PMTUD). (IPv4 PMTUD, IPv6 PMTUD)

1. Capture the failed transfer and its error traffic

Capture only systems and traffic you own or are authorized to inspect. Start before opening a fresh connection, reproduce one failed transfer, and record the interface and capture location. Keep payloads, tokens and identifying details private.

Prefer a capture near the sender of the failing large packets. For a stalled download, that may be the server: the MTU error returns toward the packet’s sender, not necessarily toward the client observing the stall.

Do not restrict the capture to TCP or the application’s port. That can exclude the ICMP evidence. If you have an existing capture, first clear its display filter and search for size errors across the whole file.

Host offloading can produce apparent packets larger than the interface MTU in a capture. These may be capture artifacts, not oversized packets on the wire. Confirm questionable sizes with a suitable external capture point or an approved, temporary offload change. (Wireshark offloading guidance)

2. Find explicit MTU errors

Enter this display filter in Wireshark:

(icmp.type == 3 && icmp.code == 4) || icmpv6.type == 2

It selects IPv4 Destination Unreachable, fragmentation needed and DF set messages and IPv6 Packet Too Big messages. The numeric values are defined in RFC 1191 and RFC 4443; the fields are documented in Wireshark’s ICMP and ICMPv6 references.

For each matching packet, expand the ICMP details and inspect:

Evidence	Where to look	What it tells you
Reported size limit	icmp.mtu or icmpv6.mtu	The next-hop MTU reported by the device generating the error
Rejected packet	IP header quoted inside the ICMP message	Which original source, destination and protocol triggered the error
Flow identity	Quoted transport header, when available	Ports and, for TCP, sequence information to match the failed transfer
Sender reaction	Subsequent packets in that direction	Whether packet size falls and acknowledgments resume

Match the quoted original packet, not just the outer ICMP addresses. The outer source is the error-generating device; the quoted packet identifies the affected flow. A short quote or encapsulated packet may not contain enough transport information to identify it conclusively. (RFC 8899)

An IPv4 next-hop MTU value of zero means the message does not supply a usable MTU—not that the path MTU is zero. (RFC 1191)

One size error followed by smaller packets and successful delivery is usually PMTUD working. Repeated related errors with no successful adaptation are more concerning.

3. Measure IP packet size, not frame or application size

Select a packet from the affected TCP connection, note its tcp.stream value, and isolate it. For example, if the stream index is 7:

tcp.stream == 7

Replace 7 with your connection’s index. Revisit ICMP errors separately—do not assume a TCP-stream filter retains every related error message.

Use these fields to compare the failed and successful packets:

• IPv4: ip.len is the total IP packet length, including its IP header. Check ip.flags.df to see whether Don’t Fragment is set.
• IPv6: for ordinary non-jumbogram packets, add 40 bytes to ipv6.plen. Payload Length excludes the fixed IPv6 header but includes extension headers.
• TCP: tcp.len is TCP data length, not total IP packet length. Header sizes are available as ip.hdr_len and tcp.hdr_len.

Wireshark documents these in its IPv4, IPv6 and TCP field references. Fixed header sizes are explained in RFC 6691, and IPv6 Payload Length in RFC 8200.

Do not compare the packet list’s frame Length directly with an IP MTU: link-layer framing is outside that MTU. For tunnels, distinguish the inner packet from the encapsulated outer packet that must fit the underlying link. (RFC 8899)

Check MSS, but do not treat it as a path measurement

Show the connection’s SYN and SYN-ACK:

tcp.stream == 7 && tcp.flags.syn == 1

Expand TCP → Options → Maximum segment size, or inspect tcp.options.mss_val.

Each endpoint advertises a receive limit: the client’s MSS constrains data sent to the client, and the server’s MSS constrains data sent to the server. MSS counts TCP data, not IP or TCP headers. When calculating the advertised MSS from an MTU, only the fixed headers are subtracted; the sender must also account for options when sizing actual data packets. An advertised MSS is therefore not proof of the current path MTU. (RFC 6691)

Illustrative example, not a measured capture: an IPv4 packet has ip.len = 1500 and DF set. A matching ICMP error reports icmp.mtu = 1400. With 20-byte IPv4 and 20-byte TCP headers and no options, at most 1360 bytes of TCP data fit that reported limit. Subsequent packets at or below 1400 bytes, followed by advancing ACKs, show adaptation to that constraint.

4. Recognize a suspected PMTU black hole

If no matching ICMP error appears, inspect retransmission candidates:

tcp.stream == 7 &&
(tcp.analysis.retransmission || tcp.analysis.fast_retransmission)

Then return to the full stream and compare packet sizes, sequence ranges and reverse-direction acknowledgments. Wireshark’s retransmission labels are analytical interpretations of the captured sequence history, not explanations of why delivery failed. (Wireshark TCP analysis)

A classic PMTU-black-hole pattern is:

1. The TCP handshake succeeds, and perhaps small data exchanges succeed.
2. Larger data packets are sent repeatedly without their sequence range being acknowledged.
3. No useful size error is visible in the sender-side capture.
4. A controlled test using smaller packets restores progress.

This pattern is described in RFC 2923 and, for IPv6, RFC 8201. It explains why a successful small ping does not rule out an MTU problem. An absent error in a capture does not by itself prove that no error reached the sender.

Before assigning that diagnosis, check alternatives:

• Receiver flow control: tcp.analysis.zero_window indicates that the receiver is advertising no room for more data, a different reason for a stall. (Wireshark TCP analysis)
• Incomplete visibility: capture loss, one-direction-only traffic or missing ACKs can make successful delivery look like failure.
• Ordinary loss: retries without a repeatable size boundary do not specifically implicate MTU.
• IPv4 fragmentation: clear the TCP-stream filter and use ip.flags.mf == 1 || ip.frag_offset > 0 to find fragments. Fragmentation shows that a datagram was split; it does not by itself prove a failed transfer. (Wireshark IPv4 fields)

For UDP-based traffic, the ICMP and IP-size checks still apply, but TCP filters do not. Use the application’s delivery evidence or an authorized receiver-side capture. Packetization-layer MTU discovery can probe and recover without ICMP feedback, so an isolated failed larger probe need not indicate an application-breaking fault. (RFC 8899)

5. Confirm the size dependency and record the result

In a controlled environment, temporarily reduce the packet size for the affected sender and destination using an appropriate route, interface or application setting. Record the original value, open a fresh connection, repeat the same transfer, and restore the setting afterward. For TCP, smaller application writes alone do not guarantee smaller IP packets; verify the resulting sizes in the capture. Do not lower an IPv6 link MTU below its 1280-byte minimum. (RFC 8200)

Check the new capture—not just the application result. Did IP packets actually become smaller? Did the previously stuck sequence range get acknowledged? Does the result repeat? Captures on both sides of the suspected bottleneck can help separate packet loss from missing error feedback.

A useful incident note distinguishes three outcomes:

• Observed size constraint: a matching ICMP error reports an MTU limit for the rejected packet.
• Observed recovery: smaller packets are delivered and the transfer resumes.
• Suspected black hole: size-dependent failure is repeatable, but the missing feedback or drop location has not been established.

Fix the identified constraint or feedback failure rather than treating a permanently reduced endpoint MTU as a universal solution. If packet size does not explain the stall, continue with TLS handshake failure analysis or TCP reset diagnosis, according to what the capture actually shows.