Mike Muuss got his new program working before sunrise. By then, his colleague Chuck Kennedy had fixed the network hardware it was supposed to investigate. Muuss had spent the night building a tool for a problem that disappeared before he could send its first test packet. He called the program ping.[1]

In December 1983, Muuss was dealing with strange behavior on the IP network at the U.S. Army's Ballistic Research Laboratory. A remark he had heard months earlier offered somewhere to start. At a DARPA meeting in Norway that July, Dave Mills had described timing electronic echoes to measure how long messages took to travel along a network path. Muuss remembered the idea and began coding.[1]

His program compiled successfully, then refused to work. The UNIX kernel underneath it lacked support for the raw ICMP sockets his code needed. Muuss described himself as "incensed." He wrote the missing kernel support as well, getting both pieces working before daybreak. Kennedy, known as Kermit, had already found and repaired the hardware by the time Muuss could launch his first ping packet.[1]

Muuss had modeled sonar and radar systems in college, and he borrowed the sound of sonar for the name. A pulse travels outward; an echo comes back. His software used messages already defined in the Internet Control Message Protocol: Echo and Echo Reply. The protocol specified that the receiving machine return the data sent to it. Timing that exchange gave Muuss a way to probe the journey to another machine and back.[1][2]

At Berkeley, developers took the source code and his kernel modifications into Berkeley UNIX. The emergency repair had been done without ping, but other people could use the next copy without writing their own overnight fix. Muuss later described his program as a thousand-line evening hack and joked that, had he known it would become his most famous accomplishment, he might have spent another day or two adding options.[1]

A modern Linux manual describes the same exchange of requests and replies, with round-trip times and packet-loss statistics. It also offers an audible option. The program can produce a sound when a reply arrives, letting someone listen for a working connection instead of watching each new line appear.[3]

At a USENIX conference, Muuss heard a story about an administrator who had taken that listening idea considerably further. According to the account Muuss recorded, the man connected ping to a vocoder, fed its output through his office stereo, and turned the volume up as loud as he could stand. Once a second, the computer shouted "Ping, ping, ping..." while he walked through the building, wiggling Ethernet connectors.[1]

Muuss called it the best ping story he had heard. The name he had borrowed from sonar had become an audible fault-finding tool: the administrator kept moving from connector to connector until the shouting stopped. That silence told him where the intermittent failure was.[1]

Sources

  1. Mike Muuss, The Story of the PING Program
  2. RFC 792, Internet Control Message Protocol
  3. Linux manual, ping(8)

Photo: Chuck Kennedy (left), Mike Muuss (center), and Doug Kingston at the Ballistic Research Laboratory. This photograph does not show the night ping was written. Ron Natalie, Wikimedia Commons, CC BY-SA 4.0. Cropped and resized; derivative under the same license.