Syslinux - Mar 2014 - Best way to deal with an idiosyncracy of Intel Boot Agent (IBA)...

All,

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.

Here's the details:
>From DHCP Options and BOOTP Vendor Extensions
(http://tools.ietf.org/html/rfc2132#section-2)

BOOTP Extension/DHCP Option Field Format

DHCP options have the same format as the BOOTP 'vendor extensions'
defined
in RFC 1497 [2]. Options may be fixed length or variable length. All
options begin with a tag octet, which uniquely identifies the option.
Fixed-length options without data consist of only a tag octet. Only options
0 and 255 are fixed length. All other options are variable-length with a
length octet following the tag octet. The value of the length octet does
not include the two octets specifying the tag and length. The length octet
is followed by "length" octets of data. Options containing NVT ASCII
data
SHOULD NOT include a trailing NULL;

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

however, the receiver of such options MUST be prepared to delete trailing
nulls if they exist.

The receiver MUST NOT require that a trailing null be included in the data.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In the case of some variable-length options the length field is a constant
but must still be specified.

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.

 BTW, Broadcom NICs and Nvidia NICs properly handle this.  (RealTek?  Well,
I've never successfully gotten a RealTek NIC to PXE boot, but that may be a
personal problem.  :-)  )

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).

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.

I'm sure this is a common problem.  How do the rest of you deal with this?

Spike

On Tue, 2014-03-18 at 00:02 -0500, Spike White wrote:
> 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.
We noticed this back in 2002, when we were still using our own TFTP
server.  My solution at the time was to simply have the TFTP server drop
a trailing 0xff from any filename.  Today, we use the following mapping
rule:

rg    (.*)?$                                 \1


Another possibility, if you have some control over options generation,
is to immediately follow the filename option with a NOOP, which is tag 0
and has no length.  This is not included in the option length, but I
expect the broken PXE stack will do the expected thing.

-- Jeff

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

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
>

On 03/17/2014 10:51 PM, Jeffrey Hutzelman wrote:
> 
> Another possibility, if you have some control over options generation,
> is to immediately follow the filename option with a NOOP, which is tag 0
> and has no length.  This is not included in the option length, but I
> expect the broken PXE stack will do the expected thing.
> 
This would almost certainly be the best option.  However, if you can't
get the filename into the filename field in the first place I expect
you're not going to be able to get control at this level.

	-hpa