jbvb@GAAK.LCS.MIT.EDU.UUCP (04/17/87)
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
Mills@UDEL.EDU (04/17/87)
Jim, Just to underscore your point, I confirmed your observation that the dcn1 name server was in fact bog, but using my own flashy toolkit. Geez, you mean somebody is still using old-style name servers? Well, it turned out the new-style (domain) name server on dcn1 is bogged as well. The bug several years old, but was revealed only by your tests just now. Dave