[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tru64-unix-managers
Subject:    bootp on alpha
From:       Dan Stromberg - OAC-CSG <strombrg () hydra ! acs ! uci ! edu>
Date:       1995-01-31 21:03:36
[Download RAW message or body]


Andrew, you've been very helpful - and despite that, I think it might
make sense to take this to the list.

I'm finding, that if I start a bootp-boot on an NCD, I can detect the
ensuing network activity with "snoop" under Solaris 2.4, and that a
"truss -f -p" of inetd (again under Solaris 2.4) shows some
bootp-related activity.  Neither is true when I try to boot our
alphastation with bootp, using either "boot ewa0" or "boot ewa0 -pro
bootp".  Given neither snoop nor truss/inetd see anything, I think I
need to be doing something differently on the dec bootp client.

I'm puzzled what it could be, tho, and do not have tons of
documentation handy.

Could it be that the dec needs a bootp server's IP address defined, in
some magic eprom environment variable, instead of broadcasting for a
server?

What have you been doing in your prom, to get the boot going?

Is there something (a device file?) I can dd|strings on, to see what
eprom variables have meanings?

Just for fun (and my own records), here's the packet I'm seeing from
the NCD, as decoded by snoop:

ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 49 arrived at 14:06:50.86
ETHER:  Packet size = 342 bytes
ETHER:  Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER:  Source      = 0:0:a7:12:3d:c3, Network Computing Devices (NCD  X-termin
al)
ETHER:  Ethertype = 0800 (IP)
ETHER:
IP:   ----- IP Header -----
IP:
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 328 bytes
IP:   Identification = 0
IP:   Flags = 0x0
IP:         .0.. .... = may fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = baa5
IP:   Source address = 0.0.0.0, OLD-BROADCAST
IP:   Destination address = 255.255.255.255, BROADCAST
IP:   No options
IP:
UDP:  ----- UDP Header -----
UDP:
UDP:  Source port = 68
UDP:  Destination port = 67
UDP:  Length = 308
UDP:  Checksum = 0000 (no checksum)
UDP:

...it looks like the packet was sent from a bootpc port, to a bootps
port:

bingy-strombrg> ypcat -k services | grep boot
68/udp bootpc          68/udp
67/udp bootps           67/udp

In message <199501301909.AA15286@hydra.acs.uci.edu>you write:
>
>
>The way I understand it works is like this:
>The firmware on the client sends out a broadcast message on the local
>network.
>
>The bootp server hears that message & responds via a bootpd process
>started from inetd.  I'm using the following entry in inetd.conf:
>bootps  dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -d 4
>
>The bootpd daemon gets the hardware address, and looks up the
>information in /etc/bootptab.  in this case it responds by telling it
>its ip address is 152.3.22.29.  It tells it that its tftp server is
>152.3.22.88, and that it should request the file
>/var/adm/ris/ris0.alpha/vmunix
>
>The client goes off & tftps /var/adm/ris/ris0.alpha/vmunix from
>152.3.22.88..
>
>If you've added the bootpd line to inetd.conf as shown above &
>restarted inetd to make sure its read inetd.conf, try booting diskless
>& see if messages like:
>Jan 30 14:03:13 renoir bootpd[8655]: request from Ethernet address x.x.x.x Sta
>rt showing up in
>/var/adm/syslog.dated/<DATE>/daemon.log
>
>Good luck
>
>Drew
>
>Dan Stromberg writes:
> > 
> > Thank you very much.
> > 
> > BTW, in the course of doing a number of sun diskless boots, I've found
> > that "snoop" is invaluable, in both debugging problems, and simply
> > learning about the stages of the boot process.
> > 
> > However, I'm finding that when I try to boot an alpha diskless, snoop
> > and etherfind do not appear to be detecting any traffic (I -haven't-
> > configured it for a full boot, I was just hoping to see a bootp (or
> > even mop) request).  Is this consistent with your experience?
> > 
> > I tried this on an alphastation 200 4/166 with "boot ewa0" and "boot
> > ewa0 -pro bootp", and on a 3000/M300 with "boot esa0".
> > 
> > It seems that the boot request should be generating -some- kind of
> > sniff'able IP traffic - altho I find it somewhat puzzling that there's
> > nothing unusual about the bootpd invocation in inetd.conf, to make it
> > listen to broadcasts.  It seems to me that either inetd would need to
> > know it should be listening for broadcasts, or the bootp client would
> > need to know what host to send it's bootp request to...
>
> > In message <199501271650.AA20491@hydra.acs.uci.edu>you write:
> > >I'd be happy to:
> > >
> > >% cat /etc/bootptab
> > >.ris.dec:hn:vm=rfc1048
> > >.ris0.alpha:tc=.ris.dec:bf=/var/adm/ris/ris0.alpha/vmunix:
> > >install:tc=.ris0.alpha:ht=ethernet:gw=152.3.22.88:ha=08002bbc52b1:ip=152.3
>.22.
> > >29:
> > >
> > >
> > >% grep tftp /etc/inetd.conf
> > >tftp   dgram   udp     wait    root     /usr/sbin/tftpd         tftpd /var
>/adm
> > >/ris
> > >
> > >If you need any more information, please feel free to ask..
> > >
> > >Drew
> > >
> > 
> > Dan Stromberg - OAC/DCS                         strombrg@uci.edu

Dan Stromberg - OAC/DCS                         strombrg@uci.edu

[prev in list] [next in list] [prev in thread] [next in thread]