marc.thielemann at biama.de
Wed Mar 24 05:29:59 UTC 2010
>>>> I defined an option space (dhcpd 4.1.1) that looks like this (sample):
>>>> option space test;
>>>> option test.option1 code 1 = unsigned integer 8;
>>>> option test.option4 code 4 = unsigned integer 16;
>>>> option test.option5 code 5 = unsigned integer 16;
>>>> option test.option6 code 7 = string;
>>>> option test.option8 code 8 = string;
>>>> option test.option9 code 9 = string;
>>>> option test.option128 code 128 = text;
>>>> option test.option130 code 130 = text;
>>>> When I now take a look at the dhcp packet the server sent out, the option 43 (vendor-encapsulated-options) includes all the values I assigned in that option space but not in the correct order. The order is: 1, 128, 130, 4, 5, 7, 8, 9 and not 1, 2, 4, 5, 7, 8, 9, 128, 130 (as I expected). Is this a bug or is there a way to define the order of the values within an option space (like dhcp-parameter-request-list)? Thanks in advance for your help.
>>> Hmm! That looks like it is going by alphabetical order of the option name.
>>> The order should not matter, but if you are particular about it you could try adding a zero to the single digit option names and see if that works, e.g. test.option01.
>> No, the option names were just samples and it makes no difference if you change them. The sorting seems actually to be done by the option code but unfortunately not in the right way. I think an option like "parameter-request-list" for the options within an option space would be helpful.
> Hmm, I'll bite on this one. The definitive source forthese type of answers is the RFCs, so quoting from RFC2132 (dhcp options):
> 8.4. Vendor Specific Information
> The Encapsulated vendor-specific options field SHOULD be encoded as a
> sequence of code/length/value fields of identical syntax to the DHCP
> options field
> 9.8. Parameter Request List
> This option is used by a DHCP client to request values for specified
> configuration parameters. The list of requested parameters is
> specified as n octets, where each octet is a valid DHCP option code
> as defined in this document.
> The client MAY list the options in order of preference. The DHCP
> server is not required to return the options in the requested order,
> but MUST try to insert the requested options in the order requested
> by the client.
> dhcp-parameter-request-list only specifies which options should be included, it does not necessarily imply the order in which they are included.
> Basically the client needs to be able to accept the vendor encapsulated options in a random order and decode them appropriately.
Thanks for the Information. I checked this and in my case the option 43 actually works even when the options are in the "wrong" order. But the RFCs say "The DHCP server ... MUST try to insert the requested options in the order requested." But how can we do this for options within an option space? As I see, there is no way to specify a parameter request list for those options. What if you have a client that takes care of the option's order?
More information about the dhcp-users