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

[Gene Cumm]

On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter
<teun.docter at brightcomputing.com> wrote:
> On 2015-09-12 04:58, Gene Cumm wrote:
>>>
>>> I've captured the following DHCP ACK:
>>>
>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
>>> length 399, xid 0xf0eb955a, secs 14, Flags [none] (0x0000)
>>>            Your-IP 10.141.20.2
>>>            Server-IP 10.141.255.254
>>>            Client-Ethernet-Address fa:16:3e:08:31:b9
>>>            Vendor-rfc1048 Extensions
>>>              Magic Cookie 0x63825363
>>>              DHCP-Message Option 53, length 1: ACK
>>>              Server-ID Option 54, length 4: 10.141.20.1
>>>              Lease-Time Option 51, length 4: 86400
>>>              RN Option 58, length 4: 43200
>>>              RB Option 59, length 4: 75600
>>>              TFTP Option 66, length 7: "master^@"
>>
>>
>> What does the name "master.openstacklocal" point to?  I typically set
>> dhcp-66 to the dotted quad string of the destination TFTP.
>
>
> Hmm, actually, it doesn't resolve.
>
>>>              BF Option 67, length 11: "pxelinux.0^@"
>>>              Subnet-Mask Option 1, length 4: 255.255.0.0
>>>              BR Option 28, length 4: 10.141.255.255
>>>              Domain-Name-Server Option 6, length 4: 10.141.20.1
>>>              Domain-Name Option 15, length 14: "openstacklocal"
>>>              Hostname Option 12, length 16: "host-10-141-20-2"
>>>              Default-Gateway Option 3, length 4: 10.141.255.250
>>>              T209 Option 209, length 45:
>>>
>>> 112.120.101.108.105.110.117.120.46.99.102.103.47.99.97.116.101.103.111.114.121.46.118.105.114.116.117.97.108.45.110.111.100.101.115.46.111.112.101.110.115.116.
>>> 97.99.107
>>>              MTU Option 26, length 2: 1450
>>>              END Option 255, length 0
>>>
>>> Followed by this TFTP request:
>>>
>>> 10.141.20.2.49152 > 10.141.20.1.tftp: [udp sum ok]  41 RRQ "ldlinux.c32"
>>> octet tsize 0 blksize 1408
>>>
>>> It should be sending that TFTP request to 10.141.255.254.
>>
>>
>> Depends on what master points at.  Otherwise, it sounds like a broken
>> interaction.
>>
>
> So, master does not resolve. But as per your suggestion, I've also tested
> with setting that field to the string "10.141.255.254". The behavior doesn't
> change though. Also, in my packet capture, with both settings, I don't see
> any DNS requests, which suggests to me it's not trying to use this field?
>
> My best guess would be that this is a bug that was introduced by the commit
> I mentioned earlier. What do you think?

Sounds like a bug that was exposed by the commit (mild difference).
Let me know if you'd like me to file a bug on your behalf.

-- 
-Gene