The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:
ping goodhost | sed -e 's/.*/ping/' | vocoder
He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.
Reminds me of setting up a dish for DirecTV. Receiver (thru stereo) beeps loudly, frequency changing via signal strength, while someone points it on the roof.
Sadly, Mike Muuss was killed in an automobile accident on November 20, 2000.
His work lives on in testament to his intellect and indomitable spirit
-- Lee A. Butler
It's interesting that ICMP ECHO_REQUEST and ECHO_REPLY predate the ping program. But indeed they are defined by http://tools.ietf.org/html/rfc792 from Sep 1981. I guess that Unix hosts were already replying to ECHO_REQUESTs even though this isn't prescribed till http://tools.ietf.org/html/rfc1122#page-42 from 1989. But I wonder what was sending ECHO_REQUEST before ping? The only other standard use of these packets I know of today is DHCP servers before handing out a lease to ensure a host isn't already using a given IP.
Phil Dykstra added ICMP Record Route support to PING, but in those early days few routers processed them
It must have been a narrow window in time when routers respected this option. My Internet career goes back to 1995 and I've never known a router to do so.
I was insanely jealous when Van Jacobson of LBL used my kernel ICMP support to write TRACEROUTE, by realizing that he could get ICMP Time-to-Live Exceeded messages when pinging by modulating the IP time to life (TTL) field. I wish I had thought of that! :-)
Asking a candidate to figure out how traceroute works is one of my interview questions, but if the author of ping didn't think of it, maybe I should drop the question. :)
The real traceroute uses UDP datagrams because routers aren't supposed to generate ICMP error messages for ICMP messages.
The Windows version I believe uses ICMP by default, and the Unix version, these days, can be asked to. I had always heard that routers do reply to ICMP, but at a lower priority.
I had that happen a few years ago. Nobody had heard of uucp either. Someone once asked me what the first browser I ever used was and when I said Lynx, they thought it was fork of Firefox.
I would like to know how they could maintain this webserver all the years... Rock solid :-)
"This Web server was one of the first 50 Web servers on the InterNet"
This is pretty hilarious from the amazon review quoted in the article:
But even with these problems, The Story About Ping has earned a place on my bookshelf, right between Stevens' Advanced Programming in the Unix Environment, and my dog-eared copy of Dante's seminal work on MS Windows, Inferno. Who can read that passage on the Windows API ("Obscure, profound it was, and nebulous, So that by fixing on its depths my sight -- Nothing whatever I discerned therein."), without shaking their head with deep understanding. But I digress.
On the latest release of Linux Mint, I did the following (it should also work for Debian, Ubuntu and other Debian-like systems):
sudo apt-get install espeak
HOST=127.0.0.1
ping $HOST | sed -u -e 's/.*/ping/' | espeak -v en
The -u (unbuffered) option to sed was required to get it to work. Apparently, the problem is that Mint's version of sed (GNU sed version 4.2.1) will buffer too aggressively for this usage when the output is not a terminal. It was a little confusing to troubleshoot since the output looked OK without the last pipe, the espeak command seemed to work when you just run it and type stuff in directly, but putting them together yielded silence without the -u switch.
"The book describes networking in terms even a child could understand, choosing to anthropomorphize the underlying packet structure. The ping packet is described as a duck, who, with other packets (more ducks), spends a certain period of time on the host machine (the wise-eyed boat). At the same time each day (I suspect this is scheduled under cron), the little packets (ducks) exit the host (boat) by way of a bridge (a bridge). From the bridge, the packets travel onto the internet (here embodied by the Yangtze River)."
: : : : :
The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:
ping goodhost | sed -e 's/.*/ping/' | vocoder
He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.