I am trying to have dhcpd match on the incoming client MAC address, but only the vendor portion of the address. I want to prevent certain devices from getting a pool address. The device I am trying to deny is not including a vendor-class-identifier in it’s packet. Therefore, I have tried numerous methods to match only the vendor portion of the MAC address as a method to specify a class which I can then deny in my pool. I can never know what the full MAC will be, so I would be happy to just match on the vendor portion.
Ethereal shows that the incoming DHCP DISCOVER has an option 61 Client Identifier with the following data. 3d07010800532aee68 That is the three hex characters 3d0701 followed by the MAC address. It identifies the Hardware type as the 3rd hex character, ie. the 0x01, then it identifies the Client MAC address as 0800532aee68. You will see below that I have tried various offsets but none are working for.
What I need is for dhcpd to give me debug information, but the man page does offer much help except -d which gives me nothing different than what was in the syslog. My class2 try is taken from the example in the dhcpd-options man page, but it does not work.
Does anyone have an suggestions? Thanks.
class “class2” {
match if substring(
binary-to-ascii(16,8,":",substring(hardware,1,6))
,0,8) = “08:00:53” ;
}
class “class3” {
match if substring(
binary-to-ascii(16,8,":",substring(option dhcp-client-identifier ,3,6))
,0,8) = “08:00:53” ;
}
subnet 10.0.0.0 netmask 255.0.0.0 {
default-lease-time 1800;
max-lease-time 3600;
pool {
range 10.1.1.54 10.1.1.56;
deny members of “class2”;
deny members of “class3”;
}
}
It seems to me, from reading a description of binary-to-ascii in man dhcp-relay, that you should be using a base of 2 rather than a base of 16, if those bytes in the tested variable are binary.
Thanks for your suggestion. I did try your suggestion, but it did not work either. After re-reading the man page I still believe it should be 16, because we are taking the data 8 bits at a time and converting it to hexidecimal, ie… base 16. We want to end up with a string of hex characters to represent the MAC address. Similar to 08:00:53.
I think dhcpd is broken, because if you look at the lease record in /var/lib/dhcp/db/dhcpd.leases that is created after the client gets the address, it shows that the client identified itself the following :
uid “\001\010\000S*\356h”;
That breaks down to \001 = 0x01 = hardware type ethernet, and \010\000S*\356h = 0x08 0x00 0x53 0x2a 0xee 0x68 = the MAC address.
I finally got it working. My problem was by defining my hex strings with leading zeroes. I was trying to match against “08:00:53”, and I should have been trying to match against “8:0:53”. I final working copy includes the leading first byte (the hardware type byte) in my string. I bet it will work to substring past that also, but I am quitting with what I have.
This is working, but it is the whole client MAC plus the leading hardware type byte
class “class6” {
match if option dhcp-client-identifier = “\001\010\000S*\356h” ;
}
This is working
class “class7” {
match if substring(option dhcp-client-identifier,0,4) = “\001\010\000S” ;
}
this works
class “class8” {
match if
binary-to-ascii(10,8,":"
,substring(option dhcp-client-identifier,0,4))
= “1:8:0:83” ;
}
this works
class “class9” {
match if
binary-to-ascii(16,8,":"
,substring(option dhcp-client-identifier,0,4))
= “1:8:0:53” ;
}
subnet 10.0.0.0 netmask 255.0.0.0 {
default-lease-time 1800;
max-lease-time 3600;
pool {
range 10.1.1.54 10.1.1.56;
deny members of “class9”;
}
}
The key was in re-reading the binary-to-ascii a third time. Thanks