[syslinux] pxelinux magic options 208

[Jeffrey Hutzelman]

--On Monday, November 08, 2010 11:39:05 AM -0500 Daniel Feenberg 
<feenberg at nber.org> wrote:

>> Look at the part about dhcp-parameter-request-list and the code
>> section just above that point on the wiki page for some information
>> about specifying it in vendor space and forcibly returning that
>> option.
>
> I have looked at those lines in the example and am baffled.

Not surprising.  The configuraton language is obscure, subtle, and not very 
well documented.

> The example
> lines are:
>
>    if exists dhcp-parameter-request-list (
>
> Do I define need to dhcp-paramteter-request-list somewhere else? If not,
> what difference does this statement make? Or is this something the dhcp
> client sends to the server? Then the next line is:

'dhcp-parameter-request-list' is the name of a DHCP option.  This statement 
is asking whether or not it exists in the request; without it, the 
following line would result in a runtime error if the request contained no 
PRL.

>    option dhcp-parameter-request-list = concat(option
> dhcp-parameter-request-list,d0,d1,d2,d3);}
>
> OK, I get it that d0 is hex for 208, etc. But are you saying I need this
> statement?

Yes.  This changes the list to include the PXELINUX-specific options, even 
though the client didn't include them in its request.  This is important 
because the server consults this list to determine what options to send; it 
won't send the client options it's not interested in, even if you define 
them in the configuration file.  This behavior is intended and expected.

> Why is this the only option statement with an = sign? Is that
> correct or a typo?

It's correct.  The = sign turns it into an assignment, whose right-hand 
side is an expression computed at runtime.  Without the =, the RHS has 
different syntax and can only be a literal value.  It also has the 
side-effect of changing at exactly what point in the server's processing 
the option value is set, but not in a way that matters here.



> I am still under the impression from an RFC and two messages in this
> mailing list that the "option pxelinux.magic" statement should be
> omitted, although the wiki says it must always be included.

I don't think you've said what version of Syslinux you're using.  Recent 
versions no longer require the magic number in option 208, but older 
versions do.  Sending it won't hurt in any case.


> What about the other statement that the wiki says must be included,
> "site-option-space"? Is that required/allowed/deprecated/forbidden with a
> recent ISC dhcp?

I don't believe the DHCP server configuration language has changed in any 
relevant way in the version you're using.  When the text you're reading 
talks about version 3.0, it means that many of the features it's using 
don't exist in _older_ verisons, which at this point would be quite old 
indeed.

The site-option-space directive is required, if you want any of the 
pxelinux.* options to be mapped into the server's response as DHCP options.

> I am also confused by your mention of vendor-space options. That looks
> much simpler, but:
>
>    Does it possibly work with ISC version 3+?

Yes, it works.

>    Do I still need to include pxelinux.magic option?

The answer is basically the same as before -- you need to include it if 
your version of Syslinux is old enough to require it, and it won't hurt in 
any case.  Note that if your client is very very old, it may not support 
use of vendor-encapsulated options; I don't remember when this appeared.

>    Do I still need to include the statements defining 208-211 (from the
>    first box)?
>
>    Does the option space statement from that box change in the case of
>    vendor options?

Yes, you still need to declare the option space and the syntax of the 
individual options.  Nothing changes here.


> When I specify vendor-option-space "pxelinux" I get the following error:
>
>    vendor-option-space "pxelinux"
>    /etc/dhcpd.conf line 121: expecting a parameter or declaration
>    vendor-option-space "pxelinux";

This is a wart in the configuration language.  The "site-option-space" 
statement expects a literal string containing the name of the option space, 
but the "vendor-option-space" statement expects a bare identifier.  Remove 
the quotes, as shown in the example, and it should work fine.

>> Also, try a packet capture.  More than likely, you'll see that your
>> server is not returning option 209 as most DHCP servers don't return
>> options that are not requested.
>
> Do you mean that if I add the dhcp-parameter-request-list, you think the
> configfile option will be transmitted, or do you mean that most servers
> do not support what I want to do? What about vendor-space?

He means that you should get out a packet trace tool and actually _look_ at 
the response your DHCP server is sending.  That will tell you whether the 
problem is your server not sending the option or the client not handling 
it, which in turn will tell you whether or not continuing to tweak the DHCP 
server configuration is a waste of time, and if not, which kinds of changes 
to try.

In fact, most servers, including the ISC server, do not send clients 
options they don't ask for, other than certain options required by the DHCP 
specification.  Modifying the parameter-request-list as shown in the wiki 
works around this by changing the server's idea of what the client asked 
for.  Alternately, all PXE client stacks should request the 
vendor-encapsulated-options option, so encoding the PXECLIENT paramaters as 
vendor options insures they will be conveyed to the client even though the 
PXE stack doesn't know to ask for them.

> The pxelinux extensions have apparently been accepted as IETF standard -

No, not all RFC's are Internet standards.  From RFC5071:

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

The code assignments are "official", but the syntax and use of PXECLIENT's 
options is not a standard.

> would one of you who have used them please post an example that will work
> with a recent ISC dhcp?

There does not appear to be anything wrong with the example in the wiki. 
What you are trying to do is not obscure, and we're not guessing; we 
actually do know how this works.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA