Network Troubleshooting: MTU/MSS Issues and Packet Capture Analysis

Background

Some users reported that a certain APP continuously failed to load content. The author investigated the issue and recorded the findings.

Before the main analysis, basic concepts are reviewed:

MTU (Maximum Transmission Unit) is the maximum size of a frame payload at the data‑link layer, excluding the frame header and FCS. The Ethernet MTU standard is 1500 bytes.

MSS (Maximum Segment Size) is the maximum TCP payload, usually announced in the SYN packet. Middleboxes can modify MSS, a practice known as MSS clamping.

In practice, when transferring large amounts of data, TCP tends to send fully‑filled packets.

The frame length shown in Wireshark does not include the 4‑byte FCS.

Problem Investigation

The author provides several packet‑capture screenshots (omitted here) and points out the anomalies:

The last few packets from the client are repeatedly retransmitted, but the server never acknowledges them.

Packet #16, sent by the client, has a length of 1514 bytes (a full‑size Ethernet frame) and is never ACKed by the server.

Earlier packets from the server (IDs 6‑9) have lengths of 1506 bytes, suggesting that an intermediate device may have altered the MSS in the client’s SYN packet to 1452, causing MTU mismatch.

Further analysis shows that the server’s SYN packet to the client reports an MSS of 1460 (normal), indicating that only one direction of MSS handling was affected. Consequently, the client did not detect the path MTU change, and full‑size packets (1514 bytes) were dropped.

To verify the hypothesis, the author suggests using ping with the “do” (do‑not‑fragment) flag and a payload size that fills the MTU:

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

If the path MTU is smaller, the command returns an error such as:

ping: local error: Message too long, mtu=1492

By adjusting the payload size or setting a specific TTL, the exact hop with the MTU problem can be identified.

Conclusion

The analysis revealed that the new version of the app added very large request parameters, causing some API GET requests to exceed the path MTU. The older version does not exhibit the issue. After confirming with the product team, the large parameters were optimized, and the problem was mitigated.

Tips: To inspect TLS‑encrypted traffic, set the SSLKEYLOGFILE environment variable to record session keys, then use Wireshark to decrypt the traffic. Chrome, Curl, and Firefox all support this method.

Final Remarks

Packet capture and analysis are powerful debugging techniques. Although the author faced several knowledge gaps during this case, systematic evidence collection and cross‑checking eventually led to a solution.