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!
As you discovered, you cannot declare host
s inside a class
. The class
declaration can only contain match
or match if
statements. If you want to group your client requests into classes using the class
construct, you could do it something like this:
class "MyHosts" {
match hardware;
}
subclass "MyHosts" 1:10:bf:48:xx:xx:xx; # host2
subclass "MyHosts" 1:10:bf:48:xx:xx:xx; # host3
In the above, the match
statement in the class
declares that subclasses will be matched by the hardware
attribute. (hardware
evaluates to the concatenation of the hardware type and the MAC address of the client; for ethernet clients, the hardware type is 1, thus the 1:
prefix in the data string of the subclass
statements.)
When a client is a member of a subclass, it is also a member of the parent class, so now you can use allow
and deny
clauses in your pool
declarations to ensure that members of MyHosts
are assigned IPs from the desired pool, e.g.:
subnet 192.168.1.0 netmask 255.255.255.0 {
...
pool {
range 192.168.1.101 192.168.1.250;
...
deny members of "MyHosts";
...
}
pool {
range 192.168.1.1 192.168.1.20;
...
allow members of "MyHosts";
...
}
}
Best Answer
Well, good news. I found an answer by myself. The answer itself was in man pages. All you need is to use EXPRESSIONS. This is correct for any option (not only bootfile-name), to which you want assign a value from client's request.
From the
man dhcp-options
:So, as you can see, the only difference between this code and mine is equal sign!
For curious one, the answer to my question is:
Did you noticed "="?