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

[Gene Cumm]

On Thu, Mar 6, 2014 at 11:20 AM, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> 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

I never said that it was against the RFC.  I was merely stating the
level of functionality of the C functions pxechn.c32 uses might not
cooperate.

> RFC2131, section 4.1, and particularly the second paragraph on page 24.

Conditionally.  "Options may appear only once, unless otherwise
specified in the options document."  I don't see any indication of any
options that DO allow it unless "The information is an opaque object
of n octets" implies arbitrary length.

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

If we assume 43 is allowed to be repeated, then the contents are an
arbitrary blob subject to vendor-specific interpretation but _SHOULD_
be in encapsulated format.

Reading over those portions of the RFCs, it comes off as the
pack/unpack functions should be able to handle a nearly arbitrary
number of instances of an option and shouldn't be repacking the option
instances together.

> 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

It appears they assumed you put an option 255 at the end of each
option 43 instance and the client will then strip those 255s.

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

   If a vendor potentially encodes more than one item of information in
   this option, then the vendor SHOULD encode the option using
   "Encapsulated vendor-specific options" as described below:

SHOULD makes me think a vendor can choose how much of the suggestion to follow.

-- 
-Gene