[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