PXE only Config [OT]

[Daniel Wells]

Thank you both very much for your replies.  This helps clarify things quite a bit.  I was afraid modifying the source code might be the only way to accomplish our needs.

I did find a project that actually was able to patch ISC DHCP to be a DHCP proxy.  The project was from 2002 but I was able to track down the person who wrote the code.  He said he tried working with ISC to get his patches added officially to the project but they were rejected due to patch size restrictions (I am not sure what that means).  You can find his patches here: http://gnu.rtin.bz/ftp.gnu.org/savannah/files/pxe-toolkit/ . He said they work with the ISC DHCP version 3.0, but couldn't guarantee they would work with later versions.

So it looks like someone already did the work but ISC wasn't interested in it at the time.

It uses conf options like:

dhcpd-operation normal;
# dhcpd-operation proxy;
# dhcpd-operation disable;

to specify which mode DHCPD ran in. Briefly looking at the patches made it look like it did what we need.  The question is whether we want to go back to the original 3.0 version in order to ensure that the patches will install.

Thanks again for your help.  The next question is whether there are other linux packages out there that can act as a DHCP proxy.

Thanks again for your help.

    - Daniel Wells



-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf Of Simon Hobson
Sent: Tuesday, December 04, 2007 8:08 AM
To: dhcp-users at isc.org
Subject: Re: PXE only Config [OT]

Bruce Hudson wrote:

>     I am saying that what you want to do will require source code changes.
>If you look at the "discover" code in the server, it is all about finding
>an existing lease or allocating one. In short, it is all about address
>management. Filling in the other parameters is almost an after-thought. I
>see no way to avoid it. Playing with "dhcp-parameter-request-list" might
>be a way to force your production DHCP server to supply PXE parameters
>that the client did not ask for but the "Client IP Address" is part of the
>basic header from the original BOOTP protocol. It is not a parameter so it
>cannot be controlled this way.
>
>     This is according to the DHCP RFC (2131) which states "designated DHCP
>server hosts allocate network addresses and deliver configuration parameters
>to dynamically configured hosts". In short, there was probably a reason why
>the people that designed PXE thought they could get away with using the
>presence of an IP address in the reply to distinguish their servers, which
>uses the DHCP protocol, from "real" DHCP servers.
>
>    In a perfect world, what PXE is trying to accomplish is what DHCPINFORM
>was designed to solve -- provide a way for a client that has an IP address
>to broadcast a second request to ask for further configuration. The PXE
>spec mentions DHCPINFORM in reference to the "boot server" dialogs. They
>should have used it earlier. (Not that that helps you. We are stuck with
>the PXE we have.)


I've been thinking that perhaps the way to get what is required (from
the ISC server) might be to strip out the address management stuff
and leave in what the dhcp-discover flow does. Then of course, all
the other stuff will need hacking to respond only to PXE requests and
ignore the rest.

Sounds like a lot of work to me - but then at least the source is
available unlike any of the commercial offerings.