I have an AT&T 4G LTE modem into an ASUS AC-3100 router which is running CyberGhost VPN. When I try to use UDP in the VPN I can ping hosts but cannot browse to any web page. It times out. I've determined it is an mtu problem. When I set mtu on my win 10 computer to 1300 it works ok and when I set it to 1330, it fails, but, of course, I can't set mtu on any of my android or apple devices so I'm stuck. Normal mtu should be 1500 throughout the network.

My question is how do I determine where the problem is? If I run pingplotter with UDP and uncheck the "fragmentation" selection I can quickly see the problem but not where the problem is. It still shows all the hops as completing when I think if a UDP packet is "lost" by a router along the way there is no record or error message given back to the source. Where along the way is the mtu set too low and how do I find it???

Any help would be greatly appreciated.

Hi there Harry,

Thanks for getting in touch with us, I'm glad to lend a hand here!

Your assumption here is totally correct - if the packet size (in bytes) exceeds the MTU of either your router or the ISPs, you won't receive information about the route (because the packets won't make it past).

The reason you're seeing route data is that one or more packets of a smaller size had gotten through before, and old route data is still on display (you can Reset&Restart a session to test this, or change your focus period).

To identify which hop/device is cutting off your connection, you can _open multiple Timeline Graphs_ by either double-clicking a hop row or with a right-click -> Show Timeline Graph. With multiple graphs, you'll be able to see which hop is blocking the route.

If you're interested, here's an article which can help explain interpreting your results:

- Interpreting Latency and Packet Loss

I hope that helps! Please let me know if this leaves you with any questions and feel free to reach out again anytime.

All the best,

Austin Berner
Quality Assurance Analyst | Pingman Tools
support@pingman.com | (208) 345-0030 ext. 1059 or 1062

In pingplotter I set the packets to udp with the defrag button unchecked and the packet length set to over 1400. Pingplotter shows responses from every hop along the way and also from the final ip address.

I thought when you send a udp packet with a length over the mtu of a router then the receiving router just drops the packet and sends nothing back to originating device???

How is it that pingplotter shows responses from all the hops when the mtu is set too high using udp???.

If I use windows command line:
ping -f www.twitter.com -l 1400
with the vpn set to udp, that ping command times out with no response.
With the windows command :
ping -f www.twitter.com -l 1300
amd the vpn set to udp, that ping command completes as normal.

For example, in pingplotter set the protocol to udp, the packet length to 1700 and uncheck the defrag button. I don't believe any router has an mtu over 1500 for normal traffic so the normal response to udp packets that size should be a timeout with no error yet pingplotter shows responses from every hop along the way.

What I'm trying to find out is how to know what/where the timeout is coming from when using udp. Can pingplotter help me do that??
thanks for all the help.

Hello there,

Here are just a few points to clarify some discrepancies you could be seeing with CMD vs. PingPlotter:

• Setting the packet size from CMD does not include the byte size for the header, which is 28 bytes. This means a 1500 byte packet would be 1528 bytes.
  
  
• Setting the packet size in PingPlotter does include the byte size for the header. If the packet size is set to 1472, it does take the header into account, which drops the payload size down to 1444 (and, consequently, is 1472 when it ships out).
  
  
• If a CMD line packet size is 1473, it would still add on a header and push the final size to 1501 - exceeding the MTU.
  
  
• If a PingPlotter packet size is 1473, it already factors in the header, so the final size would be 1473.

In a nutshell, CMD does not factor in the header size, but PingPlotter does - this would mean that a 1500 byte packet in PP would equal a command-line packet of 1472.

If PingPlotter is still able to send out unfragmented UDP packets of 1700 while specifying the VPN Network Interface in Edit -> Options -> Engine, it would be greatly appreciated if you could send over corresponding screenshots of both the target graphs and the engine options.

I hope this helps explain a few things - please let me know if this leaves you with any questions.

All the best,

Austin Berner
Quality Assurance Analyst | Pingman Tools
support@pingman.com | (208) 345-0030 ext. 1059 or 1062