On Sun, 10 Sep 1995 14:42:18 -0500 (CDT) 
 Scott Reynolds <scottr@edsi.org> wrote:

 > Jason Thorpe found the problem.  As it turned out, rpc.bootparamd wasn't 
 > at fault; instead, an incomplete ARP entry prevented it from responding.
 > The reason it's not a problem on the Sun machines is that the PROM 
 > answers ARP requests... *sigh*

Just to clarify ... it's an educated guess that the Sun PROMs are 
handling arp requests :-)  I tested this by turning off all the other 
systems on the network (so they couldn't proxy), rebooting server, 
rebooting client.  The server sent out an arp request, and got an 
answer.  The only place the answer could have come from was the booting 
Sun, which hadn't yet tftp'd boot code (which is NetBSD boot code, 
anyhow, so it wouldn't have answered).

...and I'm a bit puzzled how to solve it, as well.  I hacked on rarpd as 
much as my time allowed, and it seems like the new interface to the arp 
table is overly-complicated, but that could be lack of spare time 
talking.  Another solution might be to add arp reply capability and the 
correct semantics for doing so to libsa, but that seems a bit excessive.

Of course, the correct thing to do is have it work with any given version 
of rarpd.  Does anyone know if SunOS's rarpd adds a kernel arp entry, or 
does it simply arp and let the client reply?  A good way to test this 
would be to netboot an hp300 or mvme147 from a SunOS box after deleting 
the arp entry manually (or letting it expire).  Unfortunately, I don't 
have any SunOS boxes in the vicinity of my hp300s or mvme147.  The SunOS 
disk on my 4/260 no longer spins :(

Ciao.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939