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

[Spike White]

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