Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!ucbcad!ucbvax!CCV.BBN.COM!tmallory From: tmallory@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704162138.AA16073@ucbvax.Berkeley.EDU> Date: Thu, 16-Apr-87 16:16:51 EST Article-I.D.: ucbvax.8704162138.AA16073 Posted: Thu Apr 16 16:16:51 1987 Date-Received: Sun, 19-Apr-87 09:29:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 I just wanted to add to the debugging scenarios presented by Rudy. I have on many occasions used the message generators in our gateways to ping hosts in order to determine just where a routing problem may lie. The receipt of an echo reply packet by the gateway generates a trap message which is sent to the monitoring center. Using a gateway on a network to which the host is directly attached can show whether the host is able to communicate at all. By merely changing the source address in the ping to be the other side of the gateway, one can determine whether the host has the necessary routing information. Depending on the number of gateways under my control along the path, I can learn much about the type of problem. We often get complaints from users who cannot connect to some other host using tcp. It is very frequently case that one of the hosts does not have a route to the other network, but occasionally the problem turns out to be protocol related, as when it turned out that Sun's telnet could not use Class C internet addresses for opening connections in one direction. I don't remember whether it was client or server mode now. Such a simple low level tool can be implemented in virtually any network device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48 bytes needed to be sent to get a reply where only 28 should be necessary. The more complex your debugging aids, the more likely they won't work when you need them. Tracy Mallory BBN Communciations 617-497-3193