xref: /netbsd-src/usr.sbin/bootp/bootpd/Problems (revision 587d8cc1f58a5592ea739a7832776c4d46e122cd)
15e9d01f2Sgwr
25e9d01f2SgwrCommon problems and ways to work around them:
35e9d01f2Sgwr
45e9d01f2SgwrBootpd complains that it "can not get IP addr for HOSTNAME"
55e9d01f2Sgwr
65e9d01f2Sgwr	If the entry is a "dummy" (not a real host) used only for
75e9d01f2Sgwr	reference by other entries, put '.' in front of the name.
85e9d01f2Sgwr
95e9d01f2Sgwr	If the entry is for a real client and the IP address for
105e9d01f2Sgwr	the client can not be found using gethostbyname(), specify
115e9d01f2Sgwr	the IP address for the client using numeric form.
125e9d01f2Sgwr
135e9d01f2SgwrBootpd takes a long time to finish parsing the bootptab file:
145e9d01f2Sgwr
155e9d01f2Sgwr	Excessive startup time is usually caused by waiting for
165e9d01f2Sgwr	timeouts on failed DNS lookup operations.  If this is the
175e9d01f2Sgwr	problem, find the client names for which DNS lookup fails
185e9d01f2Sgwr	and change the bootptab to specify the IP addresses for
195e9d01f2Sgwr	those clients using numeric form.
205e9d01f2Sgwr
215e9d01f2Sgwr	When bootptab entries do not specify an ip address, bootpd
225e9d01f2Sgwr	attempts to lookup the tagname as a host name to find the
235e9d01f2Sgwr	IP address.  To suppress this default action, either make
245e9d01f2Sgwr	the entry a "dummy" or specify its IP numeric address.
255e9d01f2Sgwr
265e9d01f2Sgwr	If your DNS lookups work but are just slow, consider either
275e9d01f2Sgwr	running bootpd on the same machine as the DNS server or
285e9d01f2Sgwr	running a caching DNS server on the host running bootpd.
295e9d01f2Sgwr
305e9d01f2SgwrMy huge bootptab file causes startup time to be so long that clients
315e9d01f2Sgwrgive up waiting for a reply.
325e9d01f2Sgwr
335e9d01f2Sgwr	Truly huge bootptab files make "inetd" mode impractical.
345e9d01f2Sgwr	Start bootpd in "standalone" mode when the server boots.
355e9d01f2Sgwr
365e9d01f2Sgwr	Another possibility is to run one bootpd on each network
375e9d01f2Sgwr	segment so each one can have a smaller bootptab.  Only one
385e9d01f2Sgwr	instance of bootpd may run on one server, so you would need
395e9d01f2Sgwr	to use a different server for each network segment.
405e9d01f2Sgwr
415e9d01f2SgwrMy bootp clients are given responses with a boot file name that is
425e9d01f2Sgwrnot a fully specified path.
435e9d01f2Sgwr
445e9d01f2Sgwr	Make sure the TFTP directory or home directory tags are set:
455e9d01f2Sgwr	:td=/tftpboot:	(or)
465e9d01f2Sgwr	:hd=/usr/boot:	(for example)
475e9d01f2Sgwr
48*587d8cc1SgwrMy HP Laserjet 4 gets an error during boot: "80 service (xxxx)"
49*587d8cc1SgwrHere is an explanation of the problem from a fellow at HP:
50*587d8cc1Sgwr
51*587d8cc1Sgwr	Date: Mon, 16 Oct 95 10:16:29 MDT
52*587d8cc1Sgwr	From: James Clough <clough@hpbs3651.boi.hp.com>
53*587d8cc1Sgwr	Subject: Re: problems bootp-2.4.3 and JetDirect
54*587d8cc1Sgwr	To: bootp@andrew.cmu.edu
55*587d8cc1Sgwr
56*587d8cc1Sgwr	> I installed bootp-2.4.3 with the DHCP-patches.
57*587d8cc1Sgwr	> All went oke, except the JetDirect cards, build in in
58*587d8cc1Sgwr	> several HP Laserjet 4's. They stopped while initialising
59*587d8cc1Sgwr	> with error message '80 service (01E0)' or
60*587d8cc1Sgwr	> '... (0009)'. The DUTH HP service support did not know
61*587d8cc1Sgwr	> what the error-message was.
62*587d8cc1Sgwr
63*587d8cc1Sgwr	This problem has surfaced here more than once--each time with a
64*587d8cc1Sgwr	different hypothesized cause and proposed fix.
65*587d8cc1Sgwr
66*587d8cc1Sgwr	The real cause of this problem is the byte alignment in the vendor
67*587d8cc1Sgwr	extensions portion of the bootp packet.  Here are a few workarounds
68*587d8cc1Sgwr	that I've either used myself or heard tell of others using with
69*587d8cc1Sgwr	success:
70*587d8cc1Sgwr
71*587d8cc1Sgwr		1.  Change the name of the printer.  If the name in your
72*587d8cc1Sgwr			bootptab entry has an even number of characters,
73*587d8cc1Sgwr			change it to a name with an odd number of
74*587d8cc1Sgwr			characters.  If it's odd, make it even.
75*587d8cc1Sgwr
76*587d8cc1Sgwr		2.  Remove the logserver (lg) capability from the
77*587d8cc1Sgwr			bootptab entries for the affected printers.
78*587d8cc1Sgwr
79*587d8cc1Sgwr		3.  Use the vendor sort patches posted here in June by
80*587d8cc1Sgwr			Ron Stanonik.  They make bootpd sort the vendor
81*587d8cc1Sgwr			extensions into RFC numeric order.  It just
82*587d8cc1Sgwr			so happens that this causes them to be aligned
83*587d8cc1Sgwr			correctly.
84*587d8cc1Sgwr
85*587d8cc1Sgwr	Really, anything that changes the byte alignment in the vendor
86*587d8cc1Sgwr	tags section of the packet can work, including removing null
87*587d8cc1Sgwr	terminators from string capabilities.
88*587d8cc1Sgwr
89*587d8cc1Sgwr	James Clough
90*587d8cc1Sgwr	--
91*587d8cc1Sgwr	clough@boi.hp.com
92*587d8cc1Sgwr
93*587d8cc1Sgwr(Perhaps we need a "pad for alignment" option in bootpd. -gwr)
94