Hi Ted: I think Erich checked something in to that effect, but if you have a patch against mkdhcpconf please feel free to post it.
FYI the latest source code is available here: http://svn.oscar.openclustergroup.org/trac/oscar/browser/pkgsrc/systemin staller-oscar/trunk/bin/mkdhcpconf Cheers, Bernard > -----Original Message----- > From: Ted Powell [mailto:[EMAIL PROTECTED] On Behalf > Of Ted Powell > Sent: Tuesday, June 06, 2006 16:16 > To: Neil Costigan; Bernard Li; Erich Focht > Cc: [email protected] > Subject: ISC DHCP Server > > On Mon, Jun 05, 2006 at 09:48:29PM +0100, Neil Costigan wrote: > > > > a solution was emailed to me direct... > > thanks to Igor N. > > > > >I am not sure if you have figured out the problem you had with > > >etherboot and dhcpd in FC5. > > >Just in case, I had a similar problem - etherboot stopped > accepting > > >dhcpd offers after upgrade to FC5. > > > > > >After banging my head against the wall for a couple of > days, I have > > >found a solution. > > >For some reason etherboot wants to see the "next-server" > option in > > >the DHCP offer. And for some reason the new version of > dhcpd in FC5 > > >does not send that option. > > FC5 uses the ISC (Internet Systems Consortium) DHCP server. In any > version after 3.0.2, the following release note applies: > > - The siaddr field was being improperly set to the > server-identifier when > responding to DHCP messages. RFC2131 clarified the siaddr field as > meaning the 'next server in the bootstrap process', eg a > tftp server. > The siaddr field is now left zeroed unless next-server is > configured. > (/usr/share/doc/dhcp-3.0.3/RELNOTES) > > The relevant paragraph of RFC2131 is: > > DHCP clarifies the interpretation of the 'siaddr' field as the > address of the server to use in the next step of the client's > bootstrap process. A DHCP server may return its own address in the > 'siaddr' field, if the server is prepared to supply the next > bootstrap service (e.g., delivery of an operating system executable > image). A DHCP server always returns its own address in > the 'server > identifier' option. > (http://rfc.net/rfc2131.html) > > The change in the ISC server is appropriate, because unless > the server's > administrator tells it so, it has no business claiming > capabilities of the > host computer that it does not itself provide. If a client > machine has no > other default to try, it can always use the 'server > identifier' option to > try the machine hosting the DHCP server. The PXE code in my > host machine > does so, and successfully downloads pxelinux.0, but > pxelinux.0 does not, > and so it was trying to download its config file from 0.0.0.0. Once I > added "next-server 192.168.150.101;" to /etc/dhcpd.conf, > things worked. > > I was going to make a patch for mkdhcpconf, but I see that Bernard is > already working with that file. > > BTW, unlike the "routers" option (e.g. option routers > 192.168.150.101;), > "next-server" is a _statement_ (e.g. next-server 192.168.150.101;), > contrary to the quote from Igor N. > > > -- > Ted Powell <[EMAIL PROTECTED]> http://psg.com/~ted/ > "If you don't look, you don't know." > Dr. Sam Ting, Nobel laureate experimental physicist. > _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
