[Dnsmasq-discuss] pxe boot problem
simon at thekelleys.org.uk
Mon Oct 8 20:27:35 BST 2007
> 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.
I don't recall hitting the same problem with PXElinux, but I wasn't
specifically checking for it....
> 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.
You are right that the RFCs can be very incomplete - add the existance
of client code which violates even the well specified bits and you can
see that interoperability can be a real challenge.
My reasoning for not putting the filename into old field as well, when
the space is not needed for extra options, is the principle of least
surprise. In your situation, everything would have worked, until you
added enough options to overflow into the filename area. Then it would
mysteriously break. Always broken is better than sometimes broken.
There's not clean fix for this: the best I can come up with is a
"no-overload" flag which inhibits all the scary stuff and forces just
the simple behaviour. That would work for you and I'm happy to add it
unless someone has a better suggestion.
BTW, the dhcp-option-force stuff was added for a related situation,
where the PXE firmware doesn't request some options which are needed by
the stage one loader. This is needed to pass options to PXElinux, for one.
> thanks again,
> Steve Alexander
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss