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

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

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

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.

-- 
-Gene