> From:          "Bernard Gardner" <B.Gardner@eng.usyd.edu.au>
> Date:          Thu, 7 Mar 1996 20:14:07 -0500
> To:            Brad Salai <bsalai@law.roc.servtech.com>,
>                briggs@puma.bevd.blacksburg.va.us (Allen Briggs)
> Subject:       arp (was Re: IT WORKS!!!)
> Cc:            port-mac68k@NetBSD.ORG

> On Mar 6, 23:27, Brad Salai wrote:
> > Subject: Re: IT WORKS!!!
> 
> > > > one thing I noticed in a little preliminary testing is that arp -a
> returns
> > > > 192.168.42.1 incomplete  (I may have the ip address wrong, but the
> incomplete
> > >
> > > Hmmm...  That's a bit odd, but probably nothing to be too worried about
> > > unless it persists across a reboot with /netbsd and sync'd netbsd and
> > > arp binaries.
> > >
> > I just tried it again, I haven't for a while since it has been working, and I
> get:
> > law:~>arp -a
> > ? (192.168.42.1) at 2:60:8c:8:fd:8f permanent
> > ? (192.168.42.255) at (incomplete)
> >
> > I don't know what the second line means, but there it is. The network seems
> to work fine, I have httpd working as a proxy server. Things are -good-
> 
> arp - address resolution protocol, the system by which network protocol
> addresses are mapped into hardware addresses.
> 
> The implementation of arp that we are using caches all of its requests (like
> any good arp should), and the most recent response, to reduce network traffic.
> Note that the requests are put in the cache as they are made, and then the
> details are filled in later, thus preventing multiple arp requests for the same
> data. You may also sometimes see messages from the kernel, complaining that the
> hardware address for a certain network address has been changed. This happens
> here sometimes when our backbone network fails, and we switch to the backup
> routers - they have different ethernet addresses but use the same IP address.
> 
> The second line in the example given above can be broken down as follows:
>  ? (192.168.42.255) at (incomplete)
>  ^  ^^^^^^^^^^^^^^      ^^^^^^^^^^
>  |        |              We don't have a hardware address for this address,
>  |        |              although we have attempted to resolve it. i.e. it's
>  |        |              an incomplete entry in the arp cache
>  |        |
>  |    The network address of this entry in the arp cache.
>  |
> The host name that this aaddress reverses to using the resolver. ? means that
> the name couldn't be found.
> 
> So, the incomplete is nothing to worry about, your machine attempted to send an
> IP packet to this address, but the arp entry is as yet incomplete, because the
> host (or something else as its proxy) hasn't responded yet. The host might be
> down, or slow, or the network may be congested etc. The entry will either be
> completed or it should eventually expire from the cache.
> 
Mmm, Over on the FreeBSD group this is referred as the 'ARP BUG' a 
problem which (apparently) effects all 4.4BSD Lite based systems 
(Free/Net BSD and BSDI) which is when the system seems to create a 
duplicate arp entry and set it {incomplete} this often happens when a 
perfectly legal arp entry already exists, 

This is particularly troublesome when a machine is on a dialup connection 
which relies on a correct arp entry for routing purposes, as the 
duplicate {incomplete} entry will stop correct address resolution 
taking place, as it cannot broadcast a H/W address.

Cheers 

Phil.
 

/*   Phil Taylor phil@webleicester.co.uk
     LAN Systems - LAN/WAN Specialists */