Bug 184484

Summary: The next-server option does not get a default value
Product: [Fedora] Fedora Reporter: Russell Coker <rcoker>
Component: dhcpAssignee: David Cantrell <dcantrell>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugzilla.redhat.com
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-26 15:29:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Russell Coker 2006-03-09 02:37:27 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):
3.0.3-26

How reproducible:
Always

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. 

Additional info:
Comment 1 Jason Vas Dias 2006-03-09 09:26:46 EST
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 :

From /usr/share/doc/dhcp-3.0.2/RELNOTES:
'
- 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:

my question:
> 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
"next-server self;".
---


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.
Comment 2 Jason Vas Dias 2006-03-09 09:29:46 EST
(Sorry, replace '3.0.2' with '3.0.3' above).
Comment 3 Russell Coker 2006-03-09 17:32:12 EST
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". 
Comment 4 Red Hat Bugzilla 2007-02-05 13:55:55 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 5 David Cantrell 2007-09-26 15:29:59 EDT
Patched in dhcp-3.0.6-7.fc8.