Linux DHCP server option 43 vendor-encapsulated-options, how to format/encode?

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!

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

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;