I was under the impression that this issue had been fixed years prior.

Sadly WinMTR does not work properly anymore and is long abandoned.

The best alternative is a commercial product called PingPlotterPro. You can use it for free during a trial period.

Networking people generally don't use Windows much for troubleshooting. Windows networking behavior causes all kinds of problems and nobody wants to deal with that shit.

Last updated 9 years ago.

Sorry, I should have said!

  • See the whole path fast - don't wait on one unresponsive hop to see "deeper" hosts
  • Run ongoing traces to get path quality (per-hop packet drop & latency min/max/avg)
  • Optional jitter statistics
  • Color "strip chart" view (press 'd' twice)
  • Drawback: need sudo, unlike trace route

I would second this. I handle a lot of meetings and screenings for technical positions and quite a few Senior Network Administrators don't know or remember the basics for a lot of networking items and are completely lost when it comes to items like this. It is very much so a prevalent problem that many IT persons don't realize it's not only possible, but common to block ICMP entirely. For me, this has rendered ping unreliable as I can never truly know if we really can't reach the host or if some Network Security Admin has blocked ICMP (and often the Network persons aren't aware of this either).

Same with traceroute -- it's a common question in our interviews, "if you suspect a poor route in a given topology, which servers (client, server) should you run traceroute on?". The most common answer is just the client, without a lot of understanding that you have to consider the route from the server to the client and, like the article shared, that you only get the route info from the server you test.

Networking is still pretty tough I would say and a lot of support tickets raised for my company's product are 100% related to the network in the environment, but the Network Admin/Team lacks the depth to really investigate such issues, but knows enough to at least try to argue it's not network.

I love articles like this which clearly and plainly discuss the basic elements of networking because how you understand the basic elements fundamentally shapes how you understand network errors. The number of conversations I've had with clients who when faced with an error like "Host refused connection" when our product can't connect to a host ask with a straight face "so why did your application close the connection?" is far too high, and it's pretty disappointing on a personal level to have such discussions. Ignorance is not a sin. Reveling in ignorance is.

Telnet is more often available in older/properly configured windows systems. Curl is nix and doesn’t have the history of availability of telnet. Good to know both.

Wonder whether ssh -verbose could work in a pinch? Haven’t tried it for non-ssh coms.

The whole point of course is not every protocol nor service provides a minimalistic/widespread way of testing for basic connectivity.

If you just want to test if something is listening on a port, no need to specify the "telnet" protocol - using curl normally with the verbose option will still tell you whether the port is open, though it'll error out later down the path when it doesn't get the expected HTTP response if probing a non-HTTP port.

cat </dev/tcp/$targethost/8000