The Story of the PING Program (1997) | Hacker News Reader

The Story of the PING Program (1997)

ftp.arl.mil

171 pointsjulien42128 comments

Sadly the author of ping, Mike Muss, died in a car accident in 2000. [1]

[1]https://en.wikipedia.org/wiki/Mike_Muuss

No PONG received, connection error. RIP.

What a waste. Such talent and skill destroyed in an instant, forever.

Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants? A few weeks ago I was dealing poor performance on my cable modem. When I pinged a valid IP, I was seeing the successful packets only. It didn't show time-out packets until the summary displayed on exit. This makes it useless for quick real-time monitoring. MS ping on the other hand will show time-outs along with the successful ones.

Why is Linux ping this way? Is this a fundamental design flaw?

based on a quick perusal of the man page, the -O option will show something like "no answer yet for icmp_seq=19" when a packet doesn't get a response in time for the next one, and at least for me the default shows the icmp_seq which increases by one for each packet sent, but is only printed on each receipt (so you can spot missing ones).

'oping' fixes that issue:

  $ oping msn.com
  PING msn.com (23.101.196.141) 56 bytes of data.
  echo reply from msn.com (23.101.196.141): icmp_seq=1 timeout
  echo reply from msn.com (23.101.196.141): icmp_seq=2 timeout
  echo reply from msn.com (23.101.196.141): icmp_seq=3 timeout

Also, in standard ping, you can type Ctrl+\ (sends the QUIT signal) to get an update, e.g.

  $ ping msn.com
  PING msn.com (23.101.196.141) 56(84) bytes of data.
  <<< Ctrl+\ >>>
  7/0 packets, 100% loss

ctrl+break does the same on windows ping.

I use mtr nowadays. It's not ping but a traceroute that updates as it goes. I find it much more useful than a plain ping in most cases.

> Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants?

If you can read the output, or just recognize the difference between successful and unsuccessful lines, it works just as well for this.

> Is this a fundamental design flaw?

It's handy UX, but not the fundamental purpose of ping.

One theoretical problem with this is that it's impossible to know for sure that a packet has been lost and there's no one-size-fits-all timeout to use. On most links it doesn't matter too much, but that may be the reasoning. I've seen ping times spike in excess of two minutes on real-world internet connections (abusing 1xRTT data through a RAZR back when those were still cool) and it was... if not useful, at least interesting, to know that the data wasn't actually being dropped but was just taking a really long time.

On current iputils ping (seems to be default on most linux distros) you should be using flood ping for this:

    # ping -f x.x.x.x

As superuser or su -c / sudo of course. You'll get a nice real time bar chart of packet loss. I use it all the time for (edit: local) network testing.

That's fine on your local network. If you're pinging a system out of your local network, what you're doing is considered by many to be a denial of service attack.

http://en.wikipedia.org/wiki/Ping_flood

It's not even close to the most effective denial of service attack, but if I were to do that from my 100 Mbps Internet line I could overwhelm many company's Internet lines with a simple ping flood.

Sure. I added "local" about a second after posting for this reason. However even with -f you can just specify an interval when running tests outside your lan.

It still writes icmp_seq, which increases by one for each subsequent packet sent - based on this you can spot any missing responses. Indeed not as visible as in Windows though.

I loved the bit about piping ping through sed through vocoder, playing it on the stereo at 11, and finding the network fault by seeing which wiggled connector caused silence.

Some versions of ping have -a ("audible") option to ring the terminal bell on each response.

My first thought is that if you had to do that these days, you'd just run a terminal app on your phone over WiFi or something of the sort. My second thought is that the vocoder solution is basically setting up a one-way human-compatible wireless network over sonar.

I had a friend do the same thing when we were trying to get point-to-point wireless between our houses. He was wandering over my roof with his laptop held in the air, with it chirping 'yes yes yes yes' as it found the better areas of connectivity (his commandline used 'yes', but can't recall it).

A coworker and I once did a similar thing (Just a beep, no vocoder) to isolate a faulty switch. This switch had been causing horrible problems (data corruption style) for weeks and we just couldn't find it.

It's the only time I've ever seen my friend violent or aggressive. Upon find the switch he calmly unplugged everything, and then threw the switch at a concrete wall. I understood the sentiment.

The Amazon review by "A reader from Upper Volta, Uzbekistan" is priceless.

What software could someone write today and finish in an evening that would be as widely known and useful as PING is?

twitter? rimshot

Twitter is not known because of what it can do but because marketing

For those who want to reproduce the ping example, get espeak and run:

  ping mit.edu | sed -u 's/.*/ping/' | espeak

  ping mit.edu | sed -u 's/.*/ping pong/' | espeak

is even funnier...

I remember years ago the SunOS documentation used to have a ping joke: http://docs.oracle.com/cd/E19504-01/802-5753/6i9g71m4p/index...

The following command will work on OS X and do the voice ping:

    ping google.com | sed -l -e 's/.*/ping/' | while read line; do say $line; done

The `while read line ...` is required because the `say(1)` command will wait for an EOF when reading from a non-TTY... so it won't speak line by line.

Dr. A-hole says: Shouldn't the comment on line 283 say "Whom to ping"?

struct sockaddr whereto;/* Who to ping */

Reply on news.ycombinator.com