Syslinux - Sep 2015 - pxelinux tries to load ldlinux.c32 from DHCP server, instead of next-server

>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

On Mon, Sep 14, 2015 at 12:55 PM, Spike White via Syslinux
<syslinux at zytor.com> wrote:
>>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.
There's a missing piece in your statement.  Is your DHCP server using
DNS to resolve the value in DHCP option 66 to populate the value in
BOOTP field siaddr and then PXE clients ONLY pay attention to siaddr?
If not, your PXE clients need to have a DNS resolver.  I've never seen
a PXE client make a DNS request EXCEPT after an NBP is loaded.

-- 
-Gene

I think you're right.  I'm looking at the various DHCP configurations
that
were tested and work.  Versus the ones that don't work.

We're using a textual presentation of an IP address in DHCP option 66.  Not
a FQDN,

We are passing DNS1 and DNS2 server via DHCP option 6.  So -- PXE BIOS
cannot do DNS lookups?

Spike

On Mon, Sep 14, 2015 at 11:55 AM, Spike White <spikewhitetx at gmail.com>
wrote:
> >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
>
>