Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I admin the network for a small business which has an IPCop firewall box providing DHCP services to the network (and various other services). The DHCP server in IPCop appears to be dhcpd and IPCop provides a web-based front end to editing the configuration file.

I'm looking to use the vendor-encapsulated-options option to send particular values for DHCP options 66 and 67 to a particular vendor-class-identifier. The purpose being the auto-configuration of some VoIP phones which support DHCP options 66/67 and 43/60.

I've already managed to get options 66 tftp-server-name and 67 bootfile-name working to auto-configure the phones. But of course these options are global and sent to all DHCP clients. I'm looking to experiment with the vendor-class-indentifier and vendor-encapsulated-options DHCP options to send the auto-configure information only to the phones. I realise this is probably overkill for a small business network but this is all to broaden my knowledge.

So I started reading through some information that's out there and I just cannot work out how to encode options 66/67 within a vendor-encapsulated-options string.
Here's the relevant RFC... http://tools.ietf.org/html/rfc2132#section-8 section 8.4 And here's the man page for dhcpd http://www.daemon-systems.org/man/dhcp-options.5.html under "VENDOR ENCAPSULATED OPTIONS"

Those documents seem to suggest that the options are to be encoded in HEX format, however looking at the man page example of the vendor-encapsulated-options option...

The value of this option can be set in one of two ways.  
The first way is to simply specify the data directly,  
using a text string or a colon-separated list of hexadecimal values.  
For example:  
       option vendor-encapsulated-options
           2:4:AC:11:41:1:
           3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
           4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

When I try and decode that lot from HEX to ASCII I get the following:
????A?????????sundhcp-server17-1????????/export/root/i86pc
So I'm sure I'm not understanding the format/encoding properly.

Here's my snippet from IPCop's dhcpd.conf

subnet 192.168.1.0 netmask 255.255.255.0 #GREEN
{
        range 192.168.1.30 192.168.1.200;
        option subnet-mask 255.255.255.0;
        option domain-name "domain.com";
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.1;
        option ntp-servers 192.168.1.1;
        option netbios-name-servers 192.168.1.3;
        default-lease-time 43200;
        max-lease-time 172800;
        option vendor-encapsulated-options "hello";
        option vendor-class-identifier "snom320";
        option vendor-class-identifier "snom821";
        option bootfile-name "voipsettings/firstboot.xml";
        option tftp-server-name "http://username:password@intranet.domain.com";
} #GREEN

I have the vendor-class-identifiers set per the value submitted by the VoIP phones (Snom) in the DHCP request. The bootfile-name and tftp-server-name are the options (66/67) that I'm looking to encode in the vendor-encapsulated-options.
Snom have a guide on their wiki here...
http://wiki.snom.com/Networking/DHCP/Options#Auto_Provisioning_Options
(Apologies, my reputation is too low to post >2 links in a question)
That wiki seems to suggest that I need to encode the vendor-class-identifier as a "string of n octets"
Furthermore, the examples of the vendor-encapsulated-options given on that wiki article also return gibberish when converting from HEX to ASCII. So there's something critical that I'm not understanding here.

Can anyone give me a run-down of how to format/encode these DHCP options properly?

share|improve this question
add comment

2 Answers

up vote 7 down vote accepted

DHCP Option 43 is a bit of an odd beast. Vendors can treat it however they want - some expect the option numbers to match with the DHCP option numbers, others do not.

The basic structure is 1 byte for an option ID, 1 byte for the length of the option data (n), then n bytes of the actual option data - and, rinse and repeat.


Let's take the example from dhcp-options. They've stuck the newlines in strategic places to make it easier to read. In reality, the setting they've configured is just this:

02:04:AC:11:41:01:03:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:04:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

Which is pretty hard to read unless you know what you're looking for. Let's break down the parts:

  • Byte 1, 0x02. This says that this block is config for option number 2. How that's interpreted is up to the vendor.
  • Byte 2, 0x04. This says that the data for option 2 will occupy the next 4 bytes.
  • Bytes 3-6, 0xAC114101. These four bytes are the actual data. As you saw when you tried to decode it, it's not readable data.
  • Byte 7, the start of the next option block, 0x03. The whole chain starts over again, this says that the following config is for option 3.
  • and so on, for 3 sections

Another example, from the snom wiki page:

42:0c:68:74:74:70:3a:2f:2f:74:65:73:74:00:43:12:73:6e:6f:6d:2f:73:65:74:74:69:6e:67:73:2e:70:68:70:00;
  • Byte 1, 0x42. 42 in hex is 66, for option code 66.
  • Byte 2, 0x0c. Length of 12 bytes.
  • Bytes 3-14, 0x687474703a2f2f7465737400. This is http://test with a null byte (0x00) on the end. Not sure why they have that there.
  • Byte 15, 0x43. Option 67.
  • Byte 16, 0x12. 18 byte length.
  • Bytes 17-34, 0x736e6f6d2f73657474696e67732e70687000. snom/settings.php. Again, the null byte at the end.

So, let's say you need to construct an option 43 with http://phone.example.com as an option 66 and phonesettings.txt as option 67.

  • Byte 1, option code 66, 0x42
  • Byte 2, length of 24 bytes on http://phone.example.com, so 0x18
  • Bytes 3-26, the data. 0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
  • Byte 27, option code 67, 0x43
  • Byte 28, length of 17 bytes on phonesettings.txt, so 0x11
  • Bytes 29-45, data. 0x70686f6e6573657474696e67732e747874

So, a complete config string of :

42:18:68:74:74:70:3a:2f:2f:70:68:6f:6e:65:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d:43:11:70:68:6f:6e:65:73:65:74:74:69:6e:67:73:2e:74:78:74;

If that doesn't work, try adding the null bytes to the end of the data strings (and increase the length field accordingly) as in their example - they may either desire null bytes at the end of each option or an even number of bytes for each option's length. That's the downside of option 43 - they can do whatever they want!

share|improve this answer
    
Thanks for the excellent explanation! I think the reason I was confused was because I was trying to decode the whole thing as ascii to work out the format. But as you've pointed out, the first 2 bytes of each encoded option are decimal, not ascii. And it looks like this formatting is used in quite a few DHCP options. I've written a dirty function in PHP which I can use to build this format and also decode, I'll post as an answer. –  benbradley Oct 5 '11 at 0:54
    
The next step is to work out the dhcpd configuration syntax to combine the vendor-encapsulated-options with the vendor-class-identifier. But I don't think it's possible to do this using IPCop's DHCP admin interface. Thanks for your help! –  benbradley Oct 5 '11 at 1:20
add comment

That's definitively the most crapy way to configure the option 43. You should instead use the ISC's "vendor option space" syntax that allows you to get a human read of what you configured and avoid mistakes:

option space db;
option db.db-server code 1 = ip-address;
option db.loginid code 2 = text;
option db.db-name code 3 = text;

Jean-Yves Bisiaux

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.