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?
Best Answer
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:
Which is pretty hard to read unless you know what you're looking for. Let's break down the parts:
0x02
. This says that this block is config for option number 2. How that's interpreted is up to the vendor.0x04
. This says that the data for option 2 will occupy the next 4 bytes.0xAC114101
. These four bytes are the actual data. As you saw when you tried to decode it, it's not readable data.0x03
. The whole chain starts over again, this says that the following config is for option 3.Another example, from the snom wiki page:
0x42
. 42 in hex is 66, for option code 66.0x0c
. Length of 12 bytes.0x687474703a2f2f7465737400
. This ishttp://test
with a null byte (0x00
) on the end. Not sure why they have that there.0x43
. Option 67.0x12
. 18 byte length.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 andphonesettings.txt
as option 67.0x42
http://phone.example.com
, so0x18
0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
0x43
phonesettings.txt
, so0x11
0x70686f6e6573657474696e67732e747874
So, a complete config string of :
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!