[syslinux] Support DHCP sname field in PXELINUX

Dyks, Axel (XL) xl at xlsigned.net
Thu Jun 28 13:25:52 PDT 2007


H. Peter Anvin wrote:
> Chris Adams wrote:
>> Once upon a time, H. Peter Anvin <hpa at zytor.com> said:
>>> Chris Adams wrote:
>>>> I have discovered that the JUNOS DHCP server in Juniper J-series routers
>>>> doesn't support setting the next-server IP address field (I have filed a
>>>> bug report with Juniper and they are working on it).  Instead, it puts
>>>> the "boot server" in the sname field, which PXELINUX currently ignores.
>>>>
>>>> Here's a simple patch (vs. 3.36) that will take an IP string in the
>>>> field.  My assembly is pretty rusty, and I couldn't quite figure out how
>>>> to use the DNS resolver, so it doesn't handle a hostname.  This does
>>>> work for me with an IP string.
>>> You have no guarantee that sname is an IP string; in fact, in the 
>>> typical case it will not be.
>>>
>>> I don't think this patch is safe.
>> Well, it doesn't try to parse a null string, and it only saves the
>> resulting IP if parse_dotquad says it succeeded.  How can that not be
>> safe?
> 
> Hm.  I guess the Right Thing is too parse this as a DNS name or IP 
> address if and only if siaddr is zero.  There is no way to get the 
> source address of the DHCP reply from the PXE stack, so the ultimate 
> fallback is not available.
> 
Hmmh,

"sname" is -- according to RFC2131 -- an _optional_ null terminated string
which can really be _anything_.

Furthermore the fact that "pxelinux" is loaded, _although_ "next-server"
hasn't been set, indicates that not only the router software is broken
but also the client's PXE-ROM.
<quote source="RFC2131">
    DHCP clarifies the interpretation of the 'siaddr' field as the
    address of the server to use in the next step of the client's
    bootstrap process.  A DHCP server may return its own address in the
    'siaddr' field, if the server is prepared to supply the next
    bootstrap service (e.g., delivery of an operating system executable
    image).  A DHCP server always returns its own address in the 'server
    identifier' option.
</quote>

So why should "pxelinux" compensate for so many mistakes?

Last but not least, imagine the case that someone has configured
a DHCP/TFTP server to supply a a lot of different boot files to
different clients (by scope and/or hardware address), while
the "next-server" statement is configured globally.

For maintenenance reasons this "someone" disables the "next-server"
statement to prevent ALL clients from net booting.

Now, all those "meaning-well" PXE-ROMs and possibly "pxelinux"
wouldn't believe what they were told, but instead use "clever
tricks" to figure out, what this "someone" must have really meant ...

:-) Axel




More information about the Syslinux mailing list