Why Does My App’s Content Keep Failing? Uncovering MTU/MSS Issues with Wireshark

Background

Users reported that a certain app consistently failed to load content. Before diving into the investigation, the article reviews essential networking concepts:

MTU (Maximum Transmission Unit) is the largest frame size at the data‑link layer, excluding the frame header and FCS; Ethernet’s standard MTU is 1500 bytes.

MSS (Maximum Segment Size) is the largest TCP payload, usually advertised in the SYN packet. Middleboxes can alter MSS, a practice known as MSS clamping.

When transferring large amounts of data, TCP tends to send fully‑filled packets.

Wireshark displays frame length without the 4‑byte FCS.

Problem Investigation

The first packet‑capture screenshot (shown below) reveals that the client repeatedly retransmits packet 16, while the server never acknowledges it. Other packets are exchanged normally, indicating that the client‑server communication works except for that specific packet.

Packet 16 has a length of 1514 bytes, a fully‑filled Ethernet frame. Looking at earlier packets, the server’s packets 6‑9 have lengths of 1506 bytes, suggesting that a middle device altered the client’s MSS from the default 1460 bytes to 1452 bytes, causing the MTU to change.

Further up the capture, the server’s SYN packet still advertises an MSS of 1460, confirming that the middle device only modified the client‑to‑server direction. Consequently, the client was unaware of the reduced path MTU and sent a full‑size 1514‑byte frame that was dropped.

Further Verification

To confirm the hypothesis, the article suggests using ping with the "do not fragment" flag to probe the path MTU: ping -M do -s 1472 -c 3 -i 0.2 ip If the MTU is too small, the system returns an error such as: ping: local error: Message too long, mtu=1492 When the error is not obvious, the payload size can be gradually reduced until the ping succeeds, thereby discovering the minimum MTU. Specifying a TTL value helps locate the exact hop where the MTU restriction occurs:

ping -M do -s 1472 -c 3 -i 0.2 ip -t 3

Root Cause

Typical API GET requests are far smaller than 1460 bytes, especially with HTTP/2 header compression, so full‑size packets are rare. The investigation revealed that a new version of the app added very large parameters to the request, causing the payload to reach the MTU limit. Rolling back to the previous version eliminated the issue, and the product team is optimizing the request size.

Old request size (illustrated):

New request size (illustrated):

Tips

To inspect TLS‑encrypted traffic, set the SSLKEYLOGFILE environment variable to capture session keys, then use Wireshark to decrypt the traffic. Browsers such as Chrome, Firefox, and tools like curl support this method.

Conclusion

Packet capture and systematic analysis proved to be an efficient debugging technique, uncovering a subtle MTU/MSS mismatch caused by oversized API parameters. The case highlights the importance of understanding network fundamentals when troubleshooting mobile or backend services.