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:[email protected]";
} #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?
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://testwith 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.comas an option 66 andphonesettings.txtas option 67.0x42http://phone.example.com, so0x180x687474703a2f2f70686f6e652e6578616d706c652e636f6d0x43phonesettings.txt, so0x110x70686f6e6573657474696e67732e747874So, 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!
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:
Jean-Yves Bisiaux
Remember to use local-encapsulation: