SUMMARY: ARP Timeouts

From: Anthony Yen (tyen@mundo.eco.utexas.edu)
Date: Sun Aug 02 1992 - 10:21:58 CDT


Sun-Managers:

Hats off to the respondents:

Respondents:
============
"Andrew Luebker" <aahvdl@eye.psych.umn.edu>
fallan@awadi.com.AU (Frank Allan - Network Manager)
Jeff@digtype.airage.com (Jeff Wasilko)
Gerhard.Holzer@rcvie.co.at (Gerhard Holzer)
kjv@tampella.fi (V{{r{nen Kari)
jimh@nsd.fmc.com (Jim Hendrickson x7348 M233)
nancy@aspiring.unh.edu
"John Paul O'Brien" <john@solar.nova.edu>
feldt@phyast.nhn.uoknor.edu (Andy Feldt)
phil@pex.eecs.nwu.edu (William LeFebvre)
danny@ews7.dseg.ti.com
macphed@dvinci.usask.ca (Ian MacPhedran)
jimb@silvlis.com (Jim Budler)
Mike Raffety <miker@sbcoc.com>
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)

The responses fell into the following tabulated categories:

Tabulated Responses:
====================

 01. Check /etc/ethers is up-to-date on the boot host. (9)

macphed@dvinci.usask.ca (Ian MacPhedran) writes:
   The entry in /etc/ethers is not correct. Do a:
     ypmatch IPC_NAME ethers
   and check the result against the number displayed on power-up
   on the IPC. NOTE: single numbers less than or equal to "f" should
   be only one digit wide, alphas should be lowercase.
    e.g. 8:0:20:e:f:10
   This is the most common cause.

 02. Check /tftpboot entries on boot host. Check IP-address of boot client
      against these entries. (3)

Gerhard.Holzer@rcvie.co.at (Gerhard Holzer) writes:
Are there links like
9277435E -> boot.sun4c.sunos.4.1.2 ? #Where the first number comes from your
                                         IP-address

 03. Check /etc/exports entries on boot host. (1)

 04. Check /etc/bootparams on boot host. (2)

 05. Check boot.sun4c.sunos.4.1.2 exists. (1)

 06. If using NIS, check to make sure map has been updated and pushed. (6)

 07. Check if boot host has been booted itself as a server. (2)

 08. Check if "rarpd -a" and "rpc.bootparamd" are running. (7)

macphed@dvinci.usask.ca (Ian MacPhedran)
Try restarting your rarpd daemon. (Kill off the old one first. :-)

 09. Check physical network connections. (1)

 10. Check /etc/hosts entry on boot host. (1)

 11. Check if boot host is on same subnet as boot client. (1)

 12. Check that /etc/hostname.xx0 is renamed correctly. (1)

 13. Check for logical network problems. (1)

macphed@dvinci.usask.ca (Ian MacPhedran) writes:
   Network problems. Run tcpdump or etherfind on the server to see if
   it is seeing the rarp requests from the IPC. If it isn't, the problem
   may be that something (a router too smart for it's own good maybe)
   isn't passing these on. If it is seeing the packets, there is a
   problem on the server.

Uncategorized Responses:
========================
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer) writes:

what miniroot? there's only a miniroot when you do an install.
[Mea culpa maxima, I wasn't thinking too clearly when I posted the
original question.]

what happens when you do a "b -v"? do you get any responses?
[Never tried this; solved the problem before I had to try this.]

are you referring to getting the bootparam info and tftp'ing a
boot block?
[Yup]

Comments:
=========

As it turns out, my problem was two-fold. First, my /etc/ethers entry
was incorrect (transposed digit). This got me bootstrapped with the
tftp'd boot block.

However, I found to my chagrin that I had to NFS export my boot host's
entire /usr structure before the add_client'd filesystem would boot.
Otherwise, the boot process would complain about not being able to
find various subdirectories under /usr and then drop into a useless
shell (no /usr, /bin, whatever). This could be construed as a
security risk I think, but I'm not sure; just something about
exporting the entire /usr structure nags me at the back of my mind.

Thanks again to the entire list!

 ____
  /ony Yen - tyen@mundo.eco.utexas.edu ... Sail tough
SPARC SysAdmin - UT/Austin - Economics or go home ... Kowabunga! ...



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT