option space

[Glenn Satchell]

On 03/24/10 16:29, Marc Thielemann wrote:
>
>>>>>
>>>>> 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.
>>>
>>> Regards,
>>> Marc
>>
>> 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
>>
>> <snip>
>>
>> 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.

The parameter request option gives the server a list of options to 
return from potentially all the options it has values for. For vendor 
encapsulated options we have to know what values the client wants and 
manually include them. The vendor option is "opaque" to the server, 
which means the server just sees a bunch of bytes to send back which 
could be anything.

> What if you have a client that takes care of the option's order?

Arguably you have a client that does not conform to the RFCs. However 
there are some possibilities.

Warning. Ugly hack follows ....

If you look at section8.4 in RFC2132 it gives the option format. So you 
could manually compile the required packet data, in the order you want. 
Then specify the option contents as a hexadecimal list of octets.

eg the optionsto encode are
 >>>>> 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;

So the option values would be, integer is 32 bits, so length of 4 bytes, 
and I made up some values

43 (vendor options)
1 4 0 0 0 1 (code 1, length 4, 32 bit value of 1)
4 4 0 0 0 2 (code 4, length 4, 32 bit value of 2)
...
7 5 h e l l o (code 7, length 5, string value of "hello")
...
128 5 w o r l d (code 128, length 5, string value of "world")

or in hex

2b:
01:04:00:00:00:01:
04:04:00:00:00:02:
07:05:68:65:6c:6c:6f:
80:05:77:6f:72:6c:64

and put that all together

option vendor-encapsulated-options = 
2b:01:04:00:00:00:01:04:04:00:00:00:02:07:05:68:65:6c:6c:6f:80:05:77:6f:72:6c:64;

(see I told you there was an ugly hack :)

-- 
regards,
-glenn
--
Glenn Satchell                            |  Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia   |  do at work Dad?
mailto:glenn.satchell at uniq.com.au         |  Miss 6: He just
http://www.uniq.com.au tel:0409-458-580   |  types random stuff.