On my little network, I have a simple device which is apparently using only bootp
(as opposed to the dhcp extensions to bootp) for obtaining its address. My dhcpd.conf file looks something like this
class "user" {
match if substring(hardware, 1, 3) = 00:01:02;
log(info, "matched to a 3com";
}
class "controller" {
# tried matching based on two different styles I've seen on the net
#match if substring(hardware, 1, 3) = 00:a0:45;
match if (binary-to-ascii(16, 8, ":", substring(hardware, 0, 4)) = "1:00:a0:45");
log(info, "found a controller");
}
subnet 192.168.0.0 netmask 255.255.0.0 {
pool {
allow members of "user";
range 192.168.0.20 192.168.0.99;
log(info, "A user just attached");
}
pool {
allow members of "controller";
# never more than 1 on the network at a time
range 192.168.1.240;
log(info, "Allocated to a pwr user");
}
}
The dhcp server simply will not match to the pool it's supposed to. From the log
BOOTREQUEST from 00:a0:45:95:ce:14 via eth1: BOOTP from dynamic client and no dynamic leases
The device is DENIED for both classes. Using tcpdump and wireshark for comparing packet dumps from a laptop and the controller device (I temporarily made a class for an HP laptop, added that class to the pool used for "controller" and extended the range by 2 addresses), it seems the only difference is that the controller device is literally a bootp packet (i.e. it lacks the mandatory option 53 identifying dhcp type), and carries only option 255. The laptop was matched by dhcpd
without using the binary-to-ascii
conversion. Additionally, and curiously, the controller client IP header uses the IP address first allocated, 192.168.1.240, but in the bootp section of the packet, the ciaddr
field is 0. If it believes it has a valid lease, shouldn't it reflect this in ciaddr
?
Why is dhcpd failing to match the MAC address of this device?