94 lines
3.4 KiB
Plaintext
94 lines
3.4 KiB
Plaintext
|
|
Common problems and ways to work around them:
|
|
|
|
Bootpd complains that it "can not get IP addr for HOSTNAME"
|
|
|
|
If the entry is a "dummy" (not a real host) used only for
|
|
reference by other entries, put '.' in front of the name.
|
|
|
|
If the entry is for a real client and the IP address for
|
|
the client can not be found using gethostbyname(), specify
|
|
the IP address for the client using numeric form.
|
|
|
|
Bootpd takes a long time to finish parsing the bootptab file:
|
|
|
|
Excessive startup time is usually caused by waiting for
|
|
timeouts on failed DNS lookup operations. If this is the
|
|
problem, find the client names for which DNS lookup fails
|
|
and change the bootptab to specify the IP addresses for
|
|
those clients using numeric form.
|
|
|
|
When bootptab entries do not specify an ip address, bootpd
|
|
attempts to lookup the tagname as a host name to find the
|
|
IP address. To suppress this default action, either make
|
|
the entry a "dummy" or specify its IP numeric address.
|
|
|
|
If your DNS lookups work but are just slow, consider either
|
|
running bootpd on the same machine as the DNS server or
|
|
running a caching DNS server on the host running bootpd.
|
|
|
|
My huge bootptab file causes startup time to be so long that clients
|
|
give up waiting for a reply.
|
|
|
|
Truly huge bootptab files make "inetd" mode impractical.
|
|
Start bootpd in "standalone" mode when the server boots.
|
|
|
|
Another possibility is to run one bootpd on each network
|
|
segment so each one can have a smaller bootptab. Only one
|
|
instance of bootpd may run on one server, so you would need
|
|
to use a different server for each network segment.
|
|
|
|
My bootp clients are given responses with a boot file name that is
|
|
not a fully specified path.
|
|
|
|
Make sure the TFTP directory or home directory tags are set:
|
|
:td=/tftpboot: (or)
|
|
:hd=/usr/boot: (for example)
|
|
|
|
My HP Laserjet 4 gets an error during boot: "80 service (xxxx)"
|
|
Here is an explanation of the problem from a fellow at HP:
|
|
|
|
Date: Mon, 16 Oct 95 10:16:29 MDT
|
|
From: James Clough <clough@hpbs3651.boi.hp.com>
|
|
Subject: Re: problems bootp-2.4.3 and JetDirect
|
|
To: bootp@andrew.cmu.edu
|
|
|
|
> I installed bootp-2.4.3 with the DHCP-patches.
|
|
> All went oke, except the JetDirect cards, build in in
|
|
> several HP Laserjet 4's. They stopped while initialising
|
|
> with error message '80 service (01E0)' or
|
|
> '... (0009)'. The DUTH HP service support did not know
|
|
> what the error-message was.
|
|
|
|
This problem has surfaced here more than once--each time with a
|
|
different hypothesized cause and proposed fix.
|
|
|
|
The real cause of this problem is the byte alignment in the vendor
|
|
extensions portion of the bootp packet. Here are a few workarounds
|
|
that I've either used myself or heard tell of others using with
|
|
success:
|
|
|
|
1. Change the name of the printer. If the name in your
|
|
bootptab entry has an even number of characters,
|
|
change it to a name with an odd number of
|
|
characters. If it's odd, make it even.
|
|
|
|
2. Remove the logserver (lg) capability from the
|
|
bootptab entries for the affected printers.
|
|
|
|
3. Use the vendor sort patches posted here in June by
|
|
Ron Stanonik. They make bootpd sort the vendor
|
|
extensions into RFC numeric order. It just
|
|
so happens that this causes them to be aligned
|
|
correctly.
|
|
|
|
Really, anything that changes the byte alignment in the vendor
|
|
tags section of the packet can work, including removing null
|
|
terminators from string capabilities.
|
|
|
|
James Clough
|
|
--
|
|
clough@boi.hp.com
|
|
|
|
(Perhaps we need a "pad for alignment" option in bootpd. -gwr)
|