dennis@rlgvax.UUCP (Dennis Bednar) (10/26/85)
Its not clear to me how the the arpdump tool is to be used to aid in tracking down ethernet communications problems. There are two cases I have in mind: Case 1 Suppose that if you try to telnet to a host, it says "Trying ..." but nothing happens, and suppose the last telnet/ftp happened a "long time ago". Then what do you look for in the arpdump output to give you a clue as to what the problem is? Case 2 Supposed that you were in the middle of a telnet connection to a remote host, and suddenly your commands are no longer echoed, but the remote host is still up? My question is this: can the ARP timer information in the ARP table help you diagnose the problem? I understand that the ARP timer is restarted (value set to 0 in this implementation) when a packet is sent to a given IP address, and that the ARP timer value (measured in minutes in this implementation) gets to 20 (in this implementation), most of the information in the slot is cleared (except for the Ethernet Station address in this implementation). Therefore, if the 2 hosts were not last communicating for over 20 minutes, when an unsucessful telnet was tried (Case 1) you could now run arpdump on both hosts. Arpdump would show you that neither host has the IP address of the other host in the tables (if it did, then you would not suspect an ethernet problem, but rather a tcp or telnet problem). But for case 2, is the ARP timer timer still restarted, even though the packets are going into "thin air"? I suppose it would be, since IP is a datagram protocol, IP has no knowledge if the packet arrived, and so my guess is that arpdump tool would not be so useful in case 2. -- Dennis Bednar Computer Consoles Inc. Reston VA 703-648-3300 {decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis