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