lars@spectrum.CMC.COM (Lars Poulsen) (07/17/90)
In article <2604@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther Lumsdon) writes: > ... NCSA's tcp/ip >for MS-DOS requires (inexplicably) that the VAX PING the PC in order >to get communications to work after both machines have rebooted. ... Sounds like an ARP problem. Probably a configuration error. (I have never used NCSA telnet, nor do I have an MS-DOS machine). In order for an IP datagram to travel from one system on an ethernet to another, it must contain the receiver's ethernet address (a unique 6-byte number). The upper level protocols do not know ethernet addresses; when the datagram makes it to the ehernet device driver, it looks in a special table to see if the ethernet address for the receiver's IP address has been discovered. If not, it THROWS AWAY the datagram, and instead sends a broadcast that means "I'm looking for IP address 1.2.3.4" and expects to get back a response that says "I'm 1.2.3.4 and my ethernet address is aa:bb:cc:dd:ee:ff". This information is now used to fill in the table. So when the higher level protocol (TCP) retransmits the lost segment, the table has been filled in. It is just barely possible that the NCSA program doesn't "do" ARPs, but fills in the table from information in received IP datagrams, such as the above mentioned PING. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
ajit@sgi.com (Ajit Mayya) (07/18/90)
In article <1990Jul17.044417.17807@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: >number). The upper level protocols do not know ethernet addresses; when >the datagram makes it to the ehernet device driver, it looks in a >special table to see if the ethernet address for the receiver's IP >address has been discovered. If not, it THROWS AWAY the datagram, ^^^^^^^^^^^^^^^^^^^^^^^^^^^ No it doesn't. Atleast BSD based systems have a slot for hanging on to atleast one packet in the arp table entry. When the entry gets resolved, the packet is sent. Ofcourse, if it looks like there is going to be no incoming reply (after 3 retransmissions or whatever) the packet if freed up. Typically ARP resolution takes at most the order of milliseconds, and the packet is on its way without waiting for any retransmissions etc. If two packets are sent to the same unresolved IP destintation, the first one will be queued. When the second one comes along, the first is dropped and the second is queued and so on and so forth. I haven't looked at the Host Requirements Document lately, but I think it requires implementations to hang on to atleast one packet. ----------------------------------------------------------------------------- Ajit Mayya Silicon Graphics Inc., Advanced Systems Division ajit@asd.sgi.com Any opinions expressed above are mine, not SGI's -----------------------------------------------------------------------------
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (07/18/90)
Not all ARP implementations "throw away" the IP datagram that initiates the ARP broadcast request; ours (and other PCIP derived DOS TCP/IPs) certainly don't. Saving the IP datagram is a SHOULD in RFC 1122. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
Mills@udel (07/19/90)
James, Harrumpth. I'm glad for you and add fuzzballs to the list of ARP-keepers. There is at least one protocol (NTP) that ratchets poll interval up to 17 minutes. There is at least one vendor (*) that caches-out ARP entries every 14 minutes. There is at least one sucker who spent some days chasing that bog down. Read your SHOULD as REALLY, REALLY SHOULD. Dave