[Dnsmasq-discuss] pxe boot problem

stevea steve-alexander at adelphia.net
Sun Oct 7 20:18:21 BST 2007


Simon Kelley wrote:
> stevea wrote:
>> I am attempting to use dnsmasq-2.38 to support pxe (etherboot) for 
>> LynxOS and have run onto a problem.
>>
>> The bootfile name is supplied by the server in the rfc2132 option 
>> field, but does not appear in the main packet body (similarly the 
>> servername appears only in the option field, but this doesn't matter 
>> to me).  The following hack solves my problem and always inserts the 
>> bootfile name in the packet body (and optionally in the option field).
>>
>> --- rfc2131.c.orig      2007-10-06 10:04:58.000000000 -0400
>> +++ rfc2131.c   2007-09-25 09:46:14.000000000 -0400
>> @@ -1347,7 +1347,7 @@
>>        {
>>          if (req_options && in_list(req_options, OPTION_FILENAME))
>>            option_put_string(mess, end, OPTION_FILENAME, boot->file, 1);
>> -         else
>> +         //sja- else
>>            strncpy((char *)mess->file, boot->file, 
>> sizeof(mess->file)-1);
>>        }
>>
>>
>> dnsmasq.conf contains:
>>
>>> dhcp-boot=targe.0,lycoperdon,192.168.133.1
>>
>>
>> Is there a configuration file parameter I've missed to place the 
>> bootfile name in main packet body or is this controlled by the 
>> target/requester ?  If the latter could someone point me to the rfc 
>> that describes this please.
>>
>
> It's controlled by the requester. If the requester explicitly puts 
> option 67 into the list of options it requests, then dnsmasq assumes 
> that the client knows about the use of option 67 as an alternative to 
> the fixed "filename" field, so it sends the filename using an 
> option-67 option. That leaves the 128 byte filename field available as 
> more option space.
>
> If the client doesn't request option 67 then dnsmasq sends the 
> filename in the old way, using the 128 byte filename field.
>
> There's an agument that a client which asks for option 67 but then 
> doesn't use it is broken. Is there some whay to stop your client from 
> requesting option 67?
>
> The only RFC which deals with this, AFAIK, is 2132, the relevent bits 
> are:
>
> 9.3. Option Overload
>
>    This option is used to indicate that the DHCP 'sname' or 'file'
>    fields are being overloaded by using them to carry DHCP options. A
>    DHCP server inserts this option if the returned parameters will
>    exceed the usual space allotted for options.
>
>    If this option is present, the client interprets the specified
>    additional fields after it concludes interpretation of the standard
>    option fields.
>
>    The code for this option is 52, and its length is 1.  Legal values
>    for this option are:
>
>            Value   Meaning
>            -----   --------
>              1     the 'file' field is used to hold options
>              2     the 'sname' field is used to hold options
>              3     both fields are used to hold options
>
>     Code   Len  Value
>    +-----+-----+-----+
>    |  52 |  1  |1/2/3|
>    +-----+-----+-----+
>
> and
>
> 9.5 Bootfile name
>
>    This option is used to identify a bootfile when the 'file' field in
>    the DHCP header has been used for DHCP options.
>
>    The code for this option is 67, and its minimum length is 1.
>
>        Code  Len   Bootfile name
>       +-----+-----+-----+-----+-----+---
>       | 67  |  n  |  c1 |  c2 |  c3 | ...
>       +-----+-----+-----+-----+-----+---
>
>
>
>
> Cheers,
>
> Simon.

Sincere thanks for the rapid reply, Simon.

I've looked further into the issue and the initial requestor is some 
Intel/network card PXE firmware which does request option 67, the boot 
file name.
It successfully loads this file which is a stage-1 loader by 
Lynuxworks.  The stage-1 loader then accesses the cached packets (offer) 
collected by the Intel firmware, using the PXE standard method, but only 
examines the "old style" 128 byte bootfile name.   The stage-1 loader 
mangles this bootfilename to derive a name for the full kernel, 
subsequently loaded from the same server via tftp.  (pxe firmware loads 
targe.0 which then loads targe.1, for example).

So unfortunately the firmware and the stage-1 loader are by two 
different vendors, and since the Lynuxworks stage-1 loader is not 
dependent on a specific PXE requestor it cannot know in advance if 
option 67 was chosen by the specific firmware.  It could of course 
examine all the options looking for 67, which is a better approach.  I 
would imagine this same problem might occur in other pxe netboot code.

Still - I don't understand the omission of the old style file name and 
server name, since the offer packet did not contain option 52 indicating 
the fields were overloaded.  I find the RFCs maddeningly difficult to 
interpret in minutiae, but  I would have though that  the old server & 
file fields would be filled unless overloaded, regardless of the request 
for 67 and the servername option.

thanks again,
Steve Alexander

 




More information about the Dnsmasq-discuss mailing list