Red Hat Bugzilla – Bug 184484
The next-server option does not get a default value
Last modified: 2007-11-30 17:11:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.1 (like Gecko)
Description of problem:
The next-server statement is used to specify the host address of the
server from which the initial boot file (specified in the filename
statement) is to be loaded. Server-name should be a numeric IP
address or a domain name. If no next-server parameter applies to a
given client, the DHCP serverâs IP address is used.
The relevant section of dhcpd.conf(5) is above. The version of dhcpd in RHEL4
acts in accordance with the man page, but the version in rawhide does not.
The impact of this bug is that a dhcpd.conf that works well on RHEL4 for
Kickstart installs will fail when used on a rawhide server.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Configure a dhcpd.conf file which has no next-server directive. Run it on
RHEL4 and observe that it works with kickstart installs. Run it on a Rawhide
server and observe that it fails to operate and gives the following on VC3:
ERROR: bootp: no bootfile received
INFO: url is 0.0.0.0:/kickstart
INFO: file location: nfs://0.0.0.0:/kickstart/X.X.X.X-kickstart
Where X.X.X.X is the IP address assigned to the kickstart install.
Yes, that is correct - the upstream ISC DHCP 3.0.2+ removed the defaulting of
next-server to the DHCP server's address, to be in compliance with the RFCs :
- 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.
I mentioned this issue to David Hankins, the upstream DHCP maintainer, who
responded as follows:
> 1. dhcpd now defaults to a tftp boot file server
> ip address of 0.0.0.0 unless the 'next-server'
> option is specified - this breaks our default
> PXE boot configurations.
> I saw this entry in the change-log:
> - 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.
> My question is : what problems did defaulting to the server
> identifier cause ?
David Hankins replied:
siaddr is only one of three ways of configuring a tftp server address.
There is also a DHCP option, and the 'sname' field. If you preferred one
of these "other" two methods (say because it required a DNS resolution,
and you could then do DNS round robin on several TFTP servers, or have a
number of servers to retry through (if your bootloaders support that)),
then your clients would not operate at all - the presence of a non-zero
siaddr field prohibits this, they'll try that address and most will not
think to also check siaddr or the DHCP option.
There's of course the third case that you didn't want to specify a
TFTP server address at all. A client may not have the ability to load
from TFTP, or if it tried to, it might also be unable to continue down
the process of finding a bootable device. If a next-server is
specified, that's seen as an all-stop...go load that image and execute
it. The system may never try its internal hard drives (or even if it
does, the timeout may be lengthy and painful).
Most importantly tho, it's against the wording of the RFC, and we try to
be a reference implementation. The reference says that's not our server
identifier...we should zero it unless explicitly instructed to provide a
TFTP boot server.
I would like to encourage you towards configuring next-server in the
config, as I believe you have to include a chunk of dhcpd.conf space
stuff to provide PXE options anyway?
next-server = config-option dhcp-server-identifier;
I believe that will do what you want, since the config-option space for
the server-id is constructed (if that option is not specified) a few
lines above where next-server is evaluated. I haven't tried this, I
trust you will test it.
If it doesn't work out, we should really look at a special case config
for next-server as meaning "the calculated server id". Something like
So, in short, the dhcpd.conf of 3.0.2+ must specify an explicit
value for next server, or a default such as David suggested above:
next-server = config-option dhcp-server-identifier;
We should keep our dhcpd implementation in line with the upstream
implementation, and also be compliant with the RFCs - if we want
to do so, using an explicit next-server setting in dhcpd.conf is
the only way to go.
(Sorry, replace '3.0.2' with '3.0.3' above).
In that case please change dhcpd.conf(5) to correctly describe what is
happening. Instead of saying "If no next-server parameter applies to a
given client, the DHCP serverâs IP address is used" it should say "If no
next-server parameter applies to a given client, the address 0.0.0.0 is used".
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Patched in dhcp-3.0.6-7.fc8.