Eli Fulkerson .com HomeProjectsMturoute

mturoute.exe - Debug the MTU values between you and a host.

mturoute.exe is a small command line application that uses ICMP pings of various sizes in order to determine the MTU values on the path between itself and the target system. It also includes a "traceroute" like mode where it will attempt to determine the lowest MTU between the local host and each hop in the communication.


Listing directory https://download.elifulkerson.com/files/mturoute/2.5:
mturoute-src.zip June 24 2017 16:31:01 21530 Zip archive data, at least v2.0 to extract mturoute-src.zip.asc June 24 2017 16:35:31 801 GnuPG signature mturoute-src.zip.md5 June 24 2017 16:35:31 51 MD5 checksum mturoute-src.zip.sha1 June 24 2017 16:35:31 59 SHA1 checksum mturoute-src.zip.sha256 June 24 2017 16:35:31 83 SHA256 checksum mturoute-src.zip.sha512 June 24 2017 16:35:31 147 SHA512 checksum mturoute.exe June 24 2017 12:58:50 62464 PE32 executable (console) Intel 80386, for MS Windows mturoute.exe.asc June 24 2017 16:35:06 801 GnuPG signature mturoute.exe.md5 June 24 2017 16:35:06 47 MD5 checksum mturoute.exe.sha1 June 24 2017 16:35:06 55 SHA1 checksum mturoute.exe.sha256 June 24 2017 16:35:06 79 SHA256 checksum mturoute.exe.sha512 June 24 2017 16:35:06 143 SHA512 checksumBrowse the download server


Usage: mturoute [-t] [-f] [-m MAX_PAYLOAD_SIZE] host
   -t : Toggles 'traceroute' mode.  (Default is off)
   -f : Allow fragmentation.  This will return the max ping size that the
        target host will respond to, but not necessarily the MTU.
   -w : Set the number of milliseconds to wait for a response (default 3000).
   -r : Set the maximum number of probe retries on timeout (default = 3).
   -i : Set the interval between two echo requests.
   -d : Increases the debugging level. Reports ICMP status/failures.
   -m : Sets a maximum payload size to test. (Default is 10000)
   -v : Print version info and exit.
   -z : Fill ICMP packets with random data.
   -p : Fill ICMP packets with a specified pattern.
   -s : Skip speed optimizations.
   -x : Redact IP addresses in output.
-h,-? : Print usage information and exit.

Mturoute sends a non-fragmentable icmp probe to the target IP address with a given payload size. Since the do-not-fragment bit is set, any network equipment that has an MTU setting which is smaller than the packet size will drop the packet.

Based on the ICMP response, or the lack of a response, mturoute adjusts the payload size of its next probe. Subsequent probes are sent with a packet size midway between the highest value for which a response was received and the lowest value for which a response was not received. (For the initial conditions, the low value is 0 and the high value is whatever you set with -m, defaulting to 10000 bytes).

This process is repeated, narrowing the search space by ~50% with each cycle, terminating once the highest possible probe size has been converged upon. It then adds the 28 bytes of ICMP protocol overhead before reporting results.

Note: Speed optimization. By default (unless disabled with -s), mturoute will perform a series of educated guesses before settling down into its search pattern. If the guesswork is successful, the relatively slow search process described above is shortened and/or skipped altogether.

• In -t "traceroute" mode, mturoute performs this same process for each hop between you and the specified host. The output is abbreviated (only the +/- characters remaining to indicate progress), outputting a single MTU value for each hop.

Since each probe has to traverse the entire distance from localhost to a given hop, the reported MTU values represent the smallest MTU setting between you and the given hop, not necessarily the MTU setting between a hop and its immediate predecessor. For instance, if the MTU is narrowed on a hop midway between you and your destination, all subsequent hops will show the same small size - as your packets to more distant hops must pass through that choke point.

For example:

... despite the MTU value widening past hop C, mturoute would display the narrow, green size for both hop D and the destination host.

Due to the nature of the test, it is sensitive to packets dropped for non-MTU related reasons. Packets that are lost for other reasons will result in an incorrect MTU reading. Mturoute will attempt to re-probe to avoid dropped packets, but the mysteries of the Internet may still conspire to give you an incorrect reading. In general, the true MTU cannot be lower than the highest successful probe, but the possibility does exist that the true MTU may in fact be higher than reported.

Also, due to the asymmetrical nature of routing, this is by definition a one-sided test - as is traceroute itself. Responses originating from the target and travelling back to you are not guaranteed to travel the exact same route as your probe if multiple paths are available. Although unlikely, its possible that there might be an MTU issue on the return path which mturoute would not detect. If you have access to a computer on the far side of the network, running mturoute from there would provide information about the reverse path.

Further, again due to asymmetrical routing, there is no guarantee in traceroute mode that the path *to* a given hop is the same path that passes *through* that same hop to get to a different destination. You may see output that appears to disagree with the bottleneck diagram above.

• If the -f flag is specified, mturoute doesn't test MTU sizes. This flag will toggles off the "do not fragment" bit, which will allows intermediate routers to break mturoute's probes into multiple packets if they exceed the MTU size. Fragmented probes are re-assembled at their destination. With MTU is taken out of the equation, this mode instead reports the largest ping that a given host will respond to. This could help you determine whether fragmentation is happening properly.

• The -w setting sets the amount of time you want mturoute to wait for a response for a given probe.

• The -i setting allows you to specify the length of the interval that mturoute will wait between probes.

• The -r setting allows you to specify the number of retries that mturoute will run given a probe timeout. The default number of retries is 3.

• The -d setting instructs mturoute to output more verbose debugging information as it runs.

• The -m setting allows you to set a maximum probe size, in bits. The default is 10,000.

• The -v setting outputs the version information. Versions prior to v2.1 have no version information.

• The -s setting skips speed optimizations. (v2.2+)

• The -x setting toggles redaction of network information. If used, ip addresses will be replaced with "a.a.a.a", "b.b.b.b" etc. (v2.4+)


  • Win32 Console. Tested on XP. Should work on Vista, Windows 7 and points forward.
  • The original icmp library I used for this claimed that it compiled under Linux etc as well - which I was unable to duplicate. (I think it wanted to have ties to an older version of Wine). In v2, mturoute depends on a Windows provided library instead. It is now less likely to compile under *nix.

    Note: Turns out there is a similar-functioning equivalent in the Linux world for this sort of thing already: tracepath. If you're looking for a version of tracepath for windows, mturoute may suit your needs... and if you are seeking to compile mturoute for Linux, you should probably see if you can do it with tracepath.


  • Mturoute was originally based on the ping source code available here. The license quoted there is very liberal: """All the applications are free (BSD, GNU, or even no license) and come with the source. Don't hesitate to modify them, tweak them, enhance them. I will appreciate it if you send me your suggestions, source modifications, .. """ My modifications are free under the same arrangement as the original. Like the original author, I'd love to hear any feedback.
  • In October 2007, I received modifications from Ivan Pepelnjak, which I have collectively referred to on this page as v2. These modifications were the first significant update since the original release in 2005. Ivan's posts on mturoute and his modifications can be found on his blog.
  • Fixes, January 2008:
    * Fixed up some buffer size related bugs, hopefully squashing any mysterious crashes that people may
      have been having.  In particular, if large packet sizes crashed for you before (in theory) they
      should be working now.
    * added a "-v" option to output version information so I don't get confused.  Since I had previously
      dubbed Ivan's version "v2", I am unceremoniously dubbing this version "v2.1".  Incremental fixes
      will be v2.2, v2.3 etc.  Huge changes, if ever, might make a v3.
    * Speed fixes for dealing with unresponsive hosts.  Rather than ticking down from the base test
      value all the way to the minimum MTU, mturoute will now throw out a minimum sized packet before
      it begins.  If this minimum packet times out, we skip all the larger packets.  Under the default
      settings this should result in an approx 3 second wait for non-responsive hosts.
    * Fixed some embarrassing spelling errors and cleaned up a bit of output.  Non-responsive hosts will
      no longer report things like "------------------ host: blah max: 120 bytes", rather a message about
      them being non-responsive will be issued.
  • Update, June 2010
  • * some runtime optimizations (tries 1500 as an mtu before going whole hog and scanning the entire possible range)
    * some bug fixes
  • Update, Nov 2010
  • * Clearer output when a connection fails with an ICMP too-big response as compared to a mysterious failure where no ICMP response was recieved at all.
    * Made debug mode clearer when using the speed optimizations.  A bit.
  • Update, April 2011
  • * New "-x" option automatically redacts ip address and host information in the output, replacing them
      with "a.a.a.a", "b.b.b.b" etc.
    * Added "-h" and "-?" that show usage information.  Running the exe with no arguments will show usage
      information as well.
    * When the mtu for the previous hop is known, we start at that mtu when checking the next hop.
    * No longer double checking the successful MTU.  (1500 good... 1501 bad.... 1500 good!). 
      We now remember that we were right on the money with n-1.
    * Drastically increased the amount of information in debug "-d" mode.  Need to clean it up.
    * If the user hasn't specified agruments for -w and -r, and we get three timeouts in a row "...", 
      mturoute now assumes that ICMP responses will not be coming and adjusts its default -w and -r
      downward.  This should speed things up for people who don't get those responses and don't provide
      their own -w and -r settings.  If either option is specified or optimization is disabled, mturoute
      will not dynamically adjust its behavior.
  • Bug fix, August 2011
  • * Fixed an off by one error in certain cases
  • I welcome future modifications - so long as they are of a useful nature and within the spirit with which the software was offered originally.
  • Example Output:

    C:\mturoute-src\bin>mturoute www.example.com
    * ICMP Fragmentation is not permitted. *
    * Maximum payload is 10000 bytes. *
    - ICMP payload of 5046 bytes failed..
    - ICMP payload of 2569 bytes failed..
    + ICMP payload of 1330 bytes succeeded.
    - ICMP payload of 1949 bytes failed..
    - ICMP payload of 1639 bytes failed..
    - ICMP payload of 1484 bytes failed..
    + ICMP payload of 1407 bytes succeeded.
    + ICMP payload of 1445 bytes succeeded.
    + ICMP payload of 1464 bytes succeeded.
    - ICMP payload of 1474 bytes failed..
    + ICMP payload of 1469 bytes succeeded.
    + ICMP payload of 1471 bytes succeeded.
    + ICMP payload of 1472 bytes succeeded.
    - ICMP payload of 1473 bytes failed..
    + ICMP payload of 1472 bytes succeeded.
    + ICMP payload of 1472 bytes succeeded.
    Path MTU: 1500 bytes.
    C:\mturoute-src\bin>mturoute -t www.example.com
    mturoute to www.example.com, 30 hops max, variable sized packets
    * ICMP Fragmentation is not permitted. *
    * Maximum payload is 10000 bytes. *
     1  --+---+++-+++-++  host:  max: 1500 bytes
     2  --+---+++-+++-++  host:  max: 1500 bytes
     3  --+---+++-+++-++  host:  max: 1500 bytes
     4  --+---+++-+++-++  host:  max: 1500 bytes
     5  --+---+++-+++-++  host:  max: 1500 bytes
     6  --+---+++-+++-++  host:  max: 1500 bytes
     7  --+---+-+++++++  host:  max: 1472 bytes
     8  --+---+++-+++-++  host:  max: 1500 bytes
     9  --+---+++-+++-++  host:  max: 1500 bytes
    10  --+---+++-+++-++  host:  max: 1500 bytes
    11  --+---+++-+++-++  host:  max: 1500 bytes
    12  -----+---+-+--  host:  max: 285 bytes
    13  ---+----+-----  host:  max: 758 bytes
    14  --+---+++-+++-++  host:  max: 1500 bytes
    15  --+---+++-+++-++  host:  max: 1500 bytes
    *15 (An additional device responded for
    *15 (An additional device responded for
    16  --+---+++-+++-++  host:  max: 1500 bytes
    *16 (An additional device responded for
    17  --+---+++-+++-++  host:  max: 1500 bytes
    18  --+---+++-+++-++  host:  max: 1500 bytes
    19  --+---+++-+++-++  host:  max: 1500 bytes
    *19 (An additional device responded for
    *19 (An additional device responded for
    20  --+---+++-+++-++  host:  max: 1500 bytes
    *20 (An additional device responded for
    21  --+---+++-+++-++  host:  max: 1500 bytes
    22  --+---+++-+++-++  host:  max: 1500 bytes
    *22 (An additional device responded for
    23  --+---+++-+++-++  host:  max: 1500 bytes
    24  --+---+++-+++-++  host:  max: 1500 bytes
    *24 (An additional device responded for
    25  --+---+++-+++-++  host:  max: 1500 bytes
    *25 (An additional device responded for
    *25 (An additional device responded for

    Related Projects:

    The MTU Eyechart - visual debugging of MTU problems with your HTTP connection