[syslinux] pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server

[Spike White]

>On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm <gene.cumm at gmail.com> wrote:
>>
>...
>
>> Something like this would be preferable except it's not quite so
>> simple.  We'd need to not store BOOTP siaddr before parsing.  Store a
>> pointer to the string during parsing if serverip is unset.  After all
>> parsing, if the pointer is set, attempt to resolve then set serverip.
>> Last, if serverip is not set, copy siaddr to serverip.
>
>Perhaps a more important question is if ANY PXE implementation uses
>DHCP option 66 over BOOTP field siaddr.
>
>--
>-Gene

Gene,

Using DHCP option 66 is more maintainable than BOOTP field siaddr in a
large enterprise PXE deployment scheme.

In DHCP option 66,  you can use either a FQDN or a (textual representation
of) an IP address.

Using FQDNs is what simplifies migration (& thus, what enterprise sysadmins
would prefer).  Here's why.  Regardless of which way I go, I have to put
in a DNS change request.

I'll have to put in the DNS change request anyway, because I'm pointing my
FQDN to a new IP address.  Even if I decomm the old server and stand up a
new
server with a new FQDN, still the old name will be a DNS PTR record
pointing to the new name. Because the user community knows the old name.

Using FQDNs, when I migrate my TFTP server to a new IP address, now I
have to put in just one DNS request.

If I use BOOT field siaddr (or textual representation of IP address in DHCP
option 66), I have to put in two change requests that have to occur
simultaneously.

One change request to DHCP server maintainer, to change DHCP options.  One
request to DNS team.  To change A record to new IP address, or to convert
old FQDN to a PTR record pointing to new server name.

So yes, many PXE implementations prefer DHCP option 66 -- when it works.

Spike