Re: Re: [Etherboot-users] [PATCH] ISC dhcpd siaddr (next-server) zero default change in 3.0.2

[email protected] Thu, 15 Sep 2005 18:11:23 +0200 (CEST)
Newsgroups gmane.network.etherboot.devel
Message-ID <[email protected]>
Hi there,

> On Sep 14, 2005, at 7:35, Marty Connor wrote:
>> On Sep 14, 2005, at 8:36 AM, Harald Welte wrote:
>> 2) dhcp-3.0.2 suddenly changed the default from the dhcp server
>> address
>>    to 0.0.0.0.  ...
>
> Looks like we're not the only ones that have been bitten by this new
> behavior:
>
>      http://weblog.barnet.com.au/edwin/000110.html

or look jus 5 Weeks ago on this list or the bug tracker...

http://sourceforge.net/mailarchive/forum.php?thread_id=7898194&forum_id=6402
http://sourceforge.net/tracker/index.php?func=detail&aid=1258344&group_id=4233&atid=104233

As the Maintainer of the DHCPD Package of "eisfair - the easy internet
server" (http://www.eisfair.org/) I found this incompatibility just
after
the release of ISC dhcp 3.0.3. I now set next-server as a workaround.


RFC2131 (http://rfc.net/rfc2131.html) says:
>   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).


So the main question is: What is meant by "next step of the client's
bootstrap process"?

I guess the correct behavior would be using 'siaddr' for the TFTP-Server
but not for the DHCP-Server. I don't think it would make sense to send
DHCPREQUEST (Reply to DHCPOFFER) to the server in 'siaddr' which could
be another machine than the sender of DHCPOFFER. This message should
IMHO always be sent to the DHCP-Server in 'server identifier'.

Later, after finishing DHCP, the next step in the bootstrap process
is TFTP. So 'siaddr' should be used here.

This is necessary if the DHCP and the TFTP server are different
hardware.


What is not mentioned in the RFC is the behavior if 'siaddr' is set to
zero. Either the bootstrap process should be aborted then, or the DHCP
server could be asked if it also provides bootimages by TFTP. I think
defaulting to the DHCP server is much more convenient.

Thanks for your great work!

Bye, Max




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php