Largest MTU in TCP Optimizer

cbankston · Post by **cbankston** » Thu Apr 28, 2016 4:09 pm

Whenever I try the Largest MTU button in TCP Optimizer, I get the message: "The host you've chosen does not accept ICMP Pings, please chose a different one." The result is the same with any of the URL choices. Is there a way to complete the test?

Post by **Philip** » Thu Apr 28, 2016 9:06 pm

Some nodes are configured to give very low priority to, or not accept "pings" at all. Check your own router/modem to make sure they're not configured to block pings. You can always test in command prompt, just use the "tracert google.com" or "ping google.com" to see if it works.

cbankston · Post by **cbankston** » Thu Apr 28, 2016 9:29 pm

Philip wrote:Some nodes are configured to give very low priority to, or not accept "pings" at all. Check your own router/modem to make sure they're not configured to block pings. You can always test in command prompt, just use the "tracert google.com" or "ping google.com" to see if it works.

Pinging from command prompt works normally with no packets lost. The issue seems to be with the TCP Optimizer Largest MTU test function.

Post by **Philip** » Fri Apr 29, 2016 9:52 am

Are you running the Optimizer with admin privileges ? It should only return that message if the host you've chosen does not respond (returns all * * * results), or if there is packet loss and not all pings respond. All the URLs that are set in the Optimizer by default accept pings. Does the latency button or the trace button in the Optimizer work as expected ? Any lines with * * * in pings should indicate some packet loss, and may cause the "Largest MTU" test to fail.

cbankston · Post by **cbankston** » Fri Apr 29, 2016 12:47 pm

Philip wrote:Are you running the Optimizer with admin privileges ? It should only return that message if the host you've chosen does not respond (returns all * * * results), or if there is packet loss and not all pings respond. All the URLs that are set in the Optimizer by default accept pings. Does the latency button or the trace button in the Optimizer work as expected ? Any lines with * * * in pings should indicate some packet loss, and may cause the "Largest MTU" test to fail.

Latency test: 18 packets sent, 3 lost- timed out on 185.53.177.7

Trace works normally.

Largest MTU test: Pinging [68.67.73.20] with 1500 bytes ->Request Timed Out
The host you've chosen does not accept ICMP Pings, please chose a different one.
Result is the same for all default URL's.

Post by **Philip** » Fri Apr 29, 2016 1:08 pm

So then... the first line tells you 185.53.177.7 does not accept pings.

The problem with the MTU test is that something on your line is blocking pings, because our IP/host doesn't.

cbankston · Post by **cbankston** » Fri Apr 29, 2016 2:34 pm

Philip wrote:So then... the first line tells you 185.53.177.7 does not accept pings.

The problem with the MTU test is that something on your line is blocking pings, because our IP/host doesn't.

Why would only the MTU test pings be blocked? Pings sent by latency (except for the single IP) & trace tests & from command prompt are not being blocked. Is there some difference in the type of ping sent by the MTU test?

My computer is connected by ethernet cable to my router, which connects to a cable modem.

Post by **Philip** » Sat Apr 30, 2016 10:12 am

It could be anything, from a software firewall blocking the TCP Optimizer (are you running it as an administrator ?), to your router or ISP.

You can try to determine your MTU manually using the following method:

1. Set your MTU to 1500 (or 1492 for PPPoE).
2. In command prompt, try the following:
ping -f -l 1472 google.com (where 1472 number is the MTU you want to try, minus 28 bytes of headers, you can use your ISP instead of google.com as the host)

Note that you have to subtract 28 bytes from your MTU in that command to account for IP (20 bytes) and ICMP (8 bytes) headers. In other words, 1472+28 = 1500 MTU. If your ISP supports your 1500 MTU value set in your computer/router above, a ping with 1472 bytes should pass. If it is not supported, you will get an error ("Packet needs to be fragmented but DF set") and you should try with a smaller number. Once you find the largest packet that can go through with the above command, add 28 bytes to it and that is your maximum packet size (MTU).

I hope that makes sense.