[syslinux] PXELinux CFG file problem

[Dyks, Axel (XL)]

Dyks, Axel (XL) wrote:
> Alex Holliday wrote:
>> Wagner Ferenc wrote:
>>> "Alex Holliday" <metaphage at hotmail.com> writes:
>>>
>>>> I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
>>>> the problem is when PXELinux on the client tries to load the
>>>> configuration file.
>>> Did you check http://syslinux.zytor.com/pxe.php#tftp ?  Also, try
>>> running the tftp server in verbose mode, and look at the logs.
>> Especially you should add
>>
>> 	next-server <Your_TFTP_server_address>;
>>
>> Hi all, this fixed the problem, I don't understand why this needs to be 
>> there if it knows where to get pxelinux.1. Also where would it have been 
>> trying to get the file from??
> 
> As hpa already pointed out in his reply to
> 
>   http://syslinux.zytor.com/archives/2005-October/006033.html
> 
> <quote>
>     It worked before because previous versions of ISC DHCP defaulted to
>     "next-server == boot server".  They removed that default without warning.
> </quote>
> 
> So while "pxelinux[.0]" is loaded from "boot-server", "pxelinux" itself
> is left without a valid ip-address (next-server) to continue from.
> 
> I don't know, if it would be possible for "pxelinux" to derive "next-server"
> from "boot-server", in case that "next-server" is empty.
> But perhaps the "boot-server" information is no longer available when
> "pxelinux" is executed, otherwise -- I guess -- hpa would have already
> implemented this.
> 

I did some more research on this matter:

The RELNOTES document starting with version 3.0.3 of ISC's DHCPD lists
the following change since 3.0.2

<quote source="RELNOTES(3.0.3 and newer)">
    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.
</quote>

... though the corresponding manual page had not been updated accordingly

<quote source="dhcpd.conf(3.0.3)">
    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.
</quote>

... which has been fixed meanwhile

<quote source="dhcpd.conf(3.1.0a2)">
    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.
</quote>

Actually I do not understand, why ISC changed their interpretation of RFC2131.

<quote source="RFC2131">
    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.
</quote>

I think that having a "filename" statement in "dhcpd.conf" but no
"next-server" statement is a strong indicator for the DHCP server
('s IP address) also being used "to supply the next bootstrap service".

Regardless of being the ISC interpretation right or wrong the actually
misbehaving component in the bootstrap process seems to be the
PXE-ROM of Alex's client. Complying with RFC2131 would forbid
to silently use the DHCP server address to download "pxelinux[.0]",
if "siaddr" (next-server) is found to be empty.

So according to RFC2131 the following is true:

  * ISC may be right or may be wrong
    // I think, they are wrong or at least they are
    // guessing wrong ...

  * pxelinux's behaviour is correct
    // Well, it might not try to download anything from
    // an empty (0.0.0.0) IP-Address

  * Alex client's PXE-ROM behaves wrong
    // It shouldn't download "filename" from "DHCP-Server", if
    // siaddr (next-server) is empty

Axel