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

[Teun Docter]

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?

Thanks,
Teun