Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!GAAK.LCS.MIT.EDU!jbvb
From: jbvb@GAAK.LCS.MIT.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Ping & debugging tools
Message-ID: <8704171337.AA12197@GAAK.LCS.MIT.EDU>
Date: Fri, 17-Apr-87 08:37:36 EST
Article-I.D.: GAAK.8704171337.AA12197
Posted: Fri Apr 17 08:37:36 1987
Date-Received: Sat, 18-Apr-87 05:54:31 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 22

We include a Ping in every copy we ship.  It is the tool of choice for
dealing with support calls of the form "... I tried telnet and it just
timed out...", because it bypasses a lot of higher-level problems:
ICMP doesn't care if the PC is in its host table, trailers don't get
involved because the packets are short, everything including gateways
ought to respond to it, etc.  Our Ping displays extensive network
statistics, and can act as a server, and in this mode, we have used it
to diagnose various customer problems caused by a crazed machine
(not ours) generating excessive broadcasts of one kind or another. 

Other debugging tools we find useful on a workstation include programs
for explicitly checking nameservers, displaying who responded to a
query and what they responded with.  For instance, as of Wednesday,
4/15, DCN1's IEN-116 UDP service was giving 128.6.4.7 for
MVS.RUTGERS.EDU, whose un-transposed address is 128.6.7.4.  I could
tell I was getting a bogus address using other programs, but I would
have had to read through a lot of debugging trace to find out who, and
it wouldn't have been presented in easy-to-read formats.

James B. VanBokkelen
FTP Software Inc.
jbvb@ai.ai.mit.edu