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

On Sun, Sep 13, 2015 at 3:46 PM, Geert Stappers via Syslinux
<syslinux at zytor.com> wrote:
> On Sat, Sep 12, 2015 at 06:56:04PM -0400, Gene Cumm via Syslinux wrote:
>> On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm wrote:
>> > On Sat, Sep 12, 2015 at 10:23 AM, Geert Stappers wrote:
>> >> diff --git a/core/fs/pxe/dhcp_option.c
b/core/fs/pxe/dhcp_option.c
>> >> index 8d93a6a..b82e944 100644
>> >> --- a/core/fs/pxe/dhcp_option.c
>> >> +++ b/core/fs/pxe/dhcp_option.c
>> >> @@ -252,4 +252,6 @@ void parse_dhcp(const void *pkt, size_t
pkt_len, int pkt_type)
>> >>
>> >>      if (over_load & 2)
>> >>          parse_dhcp_options(dhcp->sname, 64, 0);
>> >> +
>> >> +    /* What about option 66, tftserver_name ?   FIXME */
>> >>  }
>> >
>> > 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.
>
> Quoting the spec ( I used
http://www.pix.net/software/pxeboot/archive/pxespec.pdf )
>
>   sname, 64 bytes, Can be overloaded if using Opt 66
>
> Hope this helps
I didn't question the specification, where BOOT field sname or DHCP
option 66 could be loaded with some string.  I questioned if any
_implementation_ (ie a PC with PXE OROM) bothers to pay attention to
sname/66 before BOOTP field siaddr or if a DHCP daemon would set
siaddr to 0 while setting sname/66.

If the BOOTP/DHCP specifications require that siaddr be set to the
first possible value of sname/66 (which I can't seem to verify with
the RFCs), then using siaddr/sname would only serve for fall back if
DNS is easier to redirect than DHCP to reconfigure.

-- 
-Gene

FYI, I can confirm that Gene's change in 229ada1 solved the problem we 
were seeing. So thank you for that.

Best regards,
Teun

On Mon, Sep 14, 2015 at 10:30 AM, Teun Docter
<teun.docter at brightcomputing.com> wrote:
> FYI, I can confirm that Gene's change in 229ada1 solved the problem we
were
> seeing. So thank you for that.
>
> Best regards,
> Teun
>
Thanks for the feedback.  I have a feeling this may have contributed
to issues that others have seen too.

-- 
-Gene

>>>
 
 I didn't question the specification, where BOOT field sname or DHCP
 option 66 could be loaded with some string.? I questioned if any
 _implementation_ (ie a PC with PXE OROM) bothers to pay attention to
 sname/66 before BOOTP field siaddr or if a DHCP daemon would set siaddr to 0
while setting sname/66.
 <<<

I have only seen clients prioritizing BOOTP fields to DHCP options. 

Best,
Patrick