ICMP, Ping, and Traceroute – What I wish I was taught (2020) | Hacker News Reader

ICMP, Ping, and Traceroute – What I wish I was taught (2020)

xkln.net

199 pointstwooster37 comments

Tip for tracerouters ... use mtr instead

brew install mtr

Try tapping 'd' twice to enable a stripchart

? for help

                             My traceroute  [v0.95]
  xxxxxxxx.local (172.16.0.2) -> news.ycombinator.com (50.1122022-07-27T23:37
  Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                     Packets               Pings
   Host                            Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 172.16.0.1                    0.0%    14   15.4  17.6  14.1  20.5   2.2
   2. (waiting for reply)
   3. 162.158.164.5                14.3%    14   34.4  71.1  16.5 145.4  47.3
   4. 198.41.160.6                  0.0%    14   32.9  36.0  30.2  43.9   3.4
   5. 198.41.140.95                 0.0%    14   61.9  45.0  35.3  64.7   9.8
   6. 99.83.70.192                  0.0%    14   40.7  36.7  33.1  49.6   4.4
   7. 150.222.214.101               0.0%    14   36.6  41.3  34.7  58.1   6.2
   8. 52.95.52.29                   0.0%    14   41.6  40.0  35.1  51.1   4.2
   9. (waiting for reply)

Yeah I tried mtr again recently. After maybe 30 seconds of working fine, it'll exit with an error like "no route to host" (even though it was getting responses before). Yeah, packet loss is exactly why I'm opening mtr: to see where on the path it occurs... how in the world does that make it crash

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

There’s also WinMTR for Windows: https://github.com/White-Tiger/WinMTR

Last updated 9 years ago.

That's not accurate:

https://github.com/traviscross/mtr

> Merge pull request #412 from 23hiro/master … 327dd3f 11 days ago

That's the Linux version, not WinMTR.

Windows has great backwards compatibility, so it still works like a charm.

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.

    sudo apt install mtr-tiny

why?

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'm interested in the topic so skimmed the whole thing but it's all just basics. Most people won't know them all, but so FYI: skip the lengthy article if you know how traceroute and ARP and ICMP work in general, what the difference is between connection times out and connection refused, and why sometimes traceroute returns more than one host for a given hop.

I wouldn't call the details he goes into with traceroute "just basics", its common even for network engineers to come to the wrong conclusion based on traceroute output, or not realising that they need more information to truly know what is going on (traceroute from both sides).

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.

ICMP blocking is a very common thing. Thus tcping was born.

If you want to do any of these types of operations from Rust, you can use https://docs.rs/netdiag/latest/netdiag/. It's very good.

> Further, the system that replies with a Destination host unreachable is the system which doesn’t have a path to the requested network - so you immediately know where to start looking.

No, that's "Destination net unreachable". Destination host unreachable means it didn't get an ARP response so it doesn't know the MAC address of the system with that IP.

Another thing that can be useful is to use tcpdump on the other side to see if the stuff sent to e.g. a TCP port is actually received:

  tcpdump -i any src port 5432 or dst port 5432

If it is now received you know you need to investigate on your receiving side, if it is not, the problem might be firewall or network.

that is the same as

  tcpdump -i any port 5432

Great article, I learned more about these daily-use tools.

An easy trick I use a lot is host OS identification via ICMP. A TTL of around 64 is Linux, ~128 is windows.

I love these types of practical approaches to networking. At least for me, I think it's the clearest way to learn about these things (rather than just read about them). Would have certainly made my university networkings course much more clear!

That's what made Crafting Interpreters[0] so compelling to me. Does anyone know any similar resources for networking?

[0] https://craftinginterpreters.com/

ping and traceroute used to be very useful tools. Then for a period of time -- maybe still ongoing -- sysadmins and some network security folks decided that by blocking ALL ICMP at their network edge, they were increasing security. (Wrong!) As a result, you get hanging traceroutes with one or two hops left and you can't use ping to verify a host is online. Worse, blocking all ICMP breaks things like MTU discovery along the path. Recently I have seen admins coming to their senses and unblocking ICMP, but it's still an old rule-of-thumb held by many.

I still keep it blocked for his reason: https://socfortress.medium.com/data-exfiltration-using-icmp-...

Once cool trick that most people don't know is that you can also ping IP addresses in octal, hex, and integer!

https://ma.ttias.be/silly-little-ip-tricks/

  >ping 0x08080808
  
  Pinging 8.8.8.8 with 32 bytes of data:
  Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
  Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
  Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
  Reply from 8.8.8.8: bytes=32 time=4ms TTL=58

Another useful tool, fping - https://linux.die.net/man/8/fping

Another common basic test for at-least windows clients that you should also add to the beginning is when you run a ping test and has the reply of your own host IP. I don’t know how many times I’ve had systems admins or engineers come to me saying there’s a network is but there NIC port is misconfigured. This usually happens due to two NICs being configured or they something else tuned incorrectly with vlan tagging at the nic under properties or the vswitch is incorrectly configured.

So maybe I misunderstood the article, but I would expect that (assuming my router is on 192.168.0.123) that

  ping 192.168.0.123

followed by

  arp -a 192.168.0.123

should tell me the MAC address of the router. But instead I get "No ARP entries found." - what's going on here?

You can use nmap for checking presence of the host, open ports and the OS machine running.

This tool has great documentation, see https://nmap.org/book/intro.html for more details

nmap in movies:

https://nmap.org/movies/

Some times you can’t make out the text in films, but that is what Enhance is for.

And on the reverse side, OS fingerprinting by the packets you receive: https://lcamtuf.coredump.cx/p0f3/

https://en.wikipedia.org/wiki/Layer_four_traceroute

Telnet to the port sometime establishes connectivity too.

In lieu of telnet, you can use curl as well:

curl -v telnet://example.com:8000

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.

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.

netcat?

nc example.com 8080 -v -w 60

cat </dev/tcp/$targethost/8000

Reply on news.ycombinator.com