[syslinux] Cannot chain to another PXE server on the same subnet

[Jeffrey Hutzelman]

On Wed, 2014-03-05 at 13:18 -0500, Gene Cumm wrote:

> Second, I notice the Altiris server specifies _3_ options of code 43,
> including one of length 253.  The pack/unpack _should_ handle this but
> may split it differently.

That's legal, and treated as if the values had been concatenated.  See
RFC2131, section 4.1, and particularly the second paragraph on page 24.
Unfortunately, a lot of implementations get this wrong.  For example,
some client implementations cannot handle encapsulated vendor options
that span more than once instance of the enclosing option 43.

In this case, it appears that the Altiris server is expecting the client
to process each instance of option 43 separately, rather than
concatenating their payloads and processing the result as if it were a
single option value.  In particular, the server is ending each instance
of option 43 with tag 255 (END).  This has the effect that a correct
client ignores everything after the first END tag(*).  This means the
client sees only the following vendor options:

  1  PXE MTFTP IP address
  2  PXE MTFTP client por
  3  PXE MTFTP server port
  4  PXE MTFTP timeout
  5  PXE MTFTP delay
  6  PXE discovery control
  8  PXE boot server list

The client would _not_ see these options:

  9  PXE boot menu
 10  PXE menu prompt control
 71  PXE boot item
224  private use?  probably altiris-specific


(*) This is actually required; see RFC 2132 section 8.4, which says:

      3) Code 255 (END), if present, signifies the end of the
         encapsulated vendor extensions, not the end of the vendor
         extensions field. If no code 255 is present, then the end of
         the enclosing vendor-specific information field is taken as the
         end of the encapsulated vendor-specific extensions field.


-- Jeff