6

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... https://www.rfc-editor.org/rfc/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?

Community
  • 1
batfastad
  • 456
  • 1
  • 10
  • 22

3 Answers3

11

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!

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 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. – batfastad Oct 05 '11 at 00: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! – batfastad Oct 05 '11 at 01:20
3

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

jyb
  • 29
  • 2
2

Remember to use local-encapsulation:

option space cisco;
option cisco.wlc code 241 = array of ip-address;
option local-encapsulation code 43 = encapsulate cisco;
option cisco.wlc 10.7.3.6, 10.7.3.2;
Per Mejdal Rasmussen
  • 31
  • 2