What software could someone write today and finish in an evening that would be as widely known and useful as PING is?
twitter? rimshot
The Story of the PING Program (1997)
21–30 of 30 posts
Re: The Story of the PING Program (1997)
#22I 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.
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).
Re: The Story of the PING Program (1997)
#23The 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
Re: The Story of the PING Program (1997)
#24Am 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…
'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) byte…
ctrl+break does the same on windows ping.
Re: The Story of the PING Program (1997)
#25I 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.
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.
Re: The Story of the PING Program (1997)
#26Re: The Story of the PING Program (1997)
#27Am 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…
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
Re: The Story of the PING Program (1997)
#28Am 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…
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.
Re: The Story of the PING Program (1997)
#29Am 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…
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.
Re: The Story of the PING Program (1997)
#30Earlier quoted context omitted.
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.