Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!hub.ucsb.edu!spectrum.CMC.COM!lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: ARP described, for newcomers
Message-ID: <1990Jul17.044417.17807@spectrum.CMC.COM>
Date: 17 Jul 90 04:44:17 GMT
References: <2509@nems.dt.navy.mil> <1990Jul10.172440.15458@spectrum.CMC.COM> <2604@nems.dt.navy.mil>
Organization: Rockwell CMC
Lines: 26

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