Path MTU Discovery Test

What is this?

This test sends packets of varying sizes from the server to your browser, and then from your browser to the server in order to check if Path MTU Discovery (PMTUD) is working properly between your browser and this server; which is hopefully indicative of your experience with PMTUD in general.

How does it work?

The first stage of the test sends varying size data packets from the server to the browser, up to the Maxium Segment Size (MSS) sent by the browser in the initial TCP SYN. There are three expected outcomes:

• The MSS is correct, the browser can receive packets of the indicated MSS; this server is limited to a MSS of 1460 (MTU 1500). In this case, you should have no trouble receiving large data packets in general.
• The MSS is not correct, but the network where there MSS is restricted does properly send ICMP Fragmentation Needed reports about packets that are too large. In this case, you should not have trouble receiving large data packets from servers (or peers) with properly configured ICMP handling, but you may have trouble with servers which don't have working ICMP.
• The MSS is not correct, and ICMP Fragmentation Needed reports were not received. In this case, you likely have trouble receiving large data packets from many servers. However, some popular servers intentionally use a lower MSS, and some others use probing techniques: probing may be immediate or after a delay.

The second stage is the opposite; the browser sends varying size of data packets to the server; packet control is less precise in this direction, and browsers do not expose the MSS in the TCP SYN-ACK received from the server. Again, there are three exepcted outcomes:

• The browser is able to send data of any size without delay. Either the browser received a correct MSS, or the browser does immediate probing. Measuring the sizes of incoming packets on the server could distinguish between these two cases, but that's not possible with normal sockets. In either case, you should have no trouble sending large data packets.
• The browser is able to send data packets up to a certain size without delay, but larger streams are delayed until path probing begins and the data is sent in sizes that are able to transit the network. In this case, you may notice some connections stall initially, but then work fine. Repeated connections to the same server may work better, if the server also sends large packets, receives ICMP Fragmentation Needed, and runs a host cache that tracks that information; in that case, the server will send a lower MSS in the SYN-ACK on connections that match the host cache, and that will likely result in the browser sending properly sized packets. This (FreeBSD) server has sysctl net.inet.tcp.hostcache.enable=0 to disable the host cache, as it interferes with probing.
• The browser is able to send data packets up to a certain size without delay, but larger streams are not received. Servers that intentionally send a lower MSS will work fine, as long as the chosen MSS is low enough; servers cannot initiate probing for this case. Often, this case is visible through packet analysis on the server; smaller packets from the client may come in fine, but MSS sized gaps often form and are not filled in; reducing the MSS to affected networks could be used to mitigate.

If the test completes, the summary data is sent to the server for possible future analysis. If the test doesn't complete, please email me

Why isn't this HTTPS?

Precise packet size control is required, and that's harder, but not impossible, to do with TLS encapsulation. Maybe later.

What about IPv6?

Coming soon. As of September 2025, I now have access to a network with MTU 1500 IPv6; once I figure out some issues with neighbor discovery, it should be a good place to run an additional test.

Contact

email welcome

source code