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

[Gene Cumm]

On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
> On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
>> 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.
>
> As I suspected, exposed.  Someone thought we should parse DHCP option
> 54 for the next server to use which is completely wrong. A DHCP,
> proxyDHCP or PXE server could point clients to other addresses but
> always record their own IP in option 54.  It should use BOOTP field
> siaddr, resolve DHCP option 66 or resolve BOOTP field sname.  Since we
> only pay attention to siaddr for now, this is a minimal change to fix.

This should help.

-- 
-Gene


diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c
index 8d93a6a..5cc0ef7 100644
--- a/core/fs/pxe/dhcp_option.c
+++ b/core/fs/pxe/dhcp_option.c
@@ -143,7 +143,6 @@ static const struct dhcp_options dhcp_opts[] = {
     {15,  local_domain},
     {43,  vendor_encaps},
     {52,  option_overload},
-    {54,  server},
     {61,  client_identifier},
     {67,  bootfile_name},
     {97,  uuid_client_identifier},