[syslinux] Best way to deal with an idiosyncracy of Intel Boot Agent (IBA)...

[Spike White]

Jeff,

Excellent suggestions.

I believe I tried putting in a NOOP.  Unfortunately, isc-dhcp-server seems
to order DHCP options sequentially.  So my NOOP (option #0) comes before
tftp filename (option #67).

Incidentally, that's why there's an FF immediately after option #67.
 Because that's option 255 (end option).  Next option in chronological
order.

Related to that, I tried offering an option 68 (which is ASCII just happens
to be 'D').  With a length of 0.  So when IBA cavalierly walked past the
end of string, it'll append a 'D' and see the length == 0 as a NULL
terminator.  So then I created a pxelinux.0D which was a symlink to
pxelinux.0

However, the client doesn't request option 68 in its DHCP DISCOVER packet,
so the ISC DHCP server doesn't send option 68 in its response packet.

I believe there's a way to force it to send an option even if not
requested.  (But I don't remember the way.)

Like you, I thought this was a "feature" that Intel fixed yrs ago. I have a
brand-new notebook (current latest model), with a brand-new Intel NIC.
 Flashed to latest firmware.  Still exhibits this behavior.  So this Intel
NIC "feature"  still exists, even in 2014.

Gene,
My option 2 was to pass a null terminator in the option 67 filename.  That
has the disadvantage that other NICs don't seem to parse this right, they
rely on the string length field exclusively.  (BTW, that's contrary to the
RFC as well.)

Just wondering how others solved this common problem.  Sounds like I
haven't missed any obvious approaches.

Spike




On Tue, Mar 18, 2014 at 11:07 AM, Gene Cumm <gene.cumm at gmail.com> wrote:

> On Tue, Mar 18, 2014 at 1:02 AM, Spike White <spikewhitetx at gmail.com>
> wrote:
>
> > I have a question on how to deal with a quirk of the Intel Boot Agent.
> >  Both for PXE boots and for EFI boots.
> >
> > I've noticed this IBA quirk for years.  According to the "DHCP options"
> > RFC, variable length DHCP options are not necessarily null-terminated.
>
> > So if I specify Bootfile name (option 67), frequently that's the last
> real
> > DHCP option.  Thus the next byte is the DHCP "end option" aka 255. The
> IBA
> > code mistakenly parses this as "/boot/efi.x64/syslinux.efi^X",  where ^X
> >  is a char with value 0xFF (255).  It requests this filename from the
> TFTP
> > server, which (of course) has no file by that name.
>
> What about specifying a normal NULL (0x0) at the end of the string?
>
> > I understand this Intel NIC idiosyncracy.  I accept this.  I'm sure
> > everyone else has seen this too.  My question is -- what is the
> recommended
> > approach to work around this?
> >
> > 1. Don't pass option 67.  Instead pass the NBP filename "old school".
> >  Using the old DHCP "file"  field.
> >    PROs:
> >         1. Works for Intel NICs.
> >         2. "file" field is a null-terminated string (according to RFC
> 2131).
> >    CONs:
> >         1. Some other NICs seem to prefer option 67 over "file" field.
> >         2. Lame DHCP servers (like old MS ones) set both fields (option
> 67
> > and "file" field) whenever you set either.
> >         3. Limited to 64 chars max (including null terminator).
>
> This seems to work best in my experience although I've never seen MS
> DHCP use option 67 in a packet (I've only seen MS DHCP since MS
> Windows Server 2003).
>
> > 2. Literally embed a null-terminator at the end of option 67.
> >    PROs:
> >        Works for Intel NICs.
> >    CONs:
> >         I believe some other NICs don't handle this null terminator right
> > (might be mistaken).
> >
> > 3. Using tftp-hpa's filename remapping to strip off any 0xFF char on end.
> >    PROs:
> >         Works for all NICs.
> >    CONs:
> >        Only works if you're using tftp-hpa TFTP server.  Many other PXE
> > deployments don't have this filename remapping capability.
>
>
> --
> -Gene
>