Has anoyone come across the issue where your DHCP server makes an offer, but when the DHCPREQUEST is received, the server says the lease is unavailable? I am having problems with my DHCP server doing this very thing, and I am fairly certain what the problem is, just not how to fix it.

When the client sends the DHCPDISCOVER, it sends an option 43 (vendor-encapsulated-options), and my DHCP server reads this field to determine the machine type (using a class statement). The server responds with a DHCPOFFER, to which the client responds with a DHCPREQUEST, however, in this request, it doesn't send the option 43, so it can't be matched to the correct class. This causes the DHCP server to reject the request. The lease is written to the dhcpd.leases file after the offer is made, so I am not sure how to make this work.

Attached is my dhcpd.conf

allow booting;
allow bootp;

ddns-update-style interim;

class "TEST" {
match if (substring(option vendor-encapsulated-options, 2, 4) = 34:36:39:34);
}

subnet 192.168.0.0 netmask 255.255.255.0 {

authoritative;

option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option broadcast-address 255.255.255.1;

option nis-domain "test.com";
option domain-name "test.com";
option domain-name-servers 192.168.0.1;

option time-offset -6; # Central Standard Time
option ntp-servers 192.168.0.1;
option netbios-name-servers 192.168.0.1;

pool {
allow members of "TEST";
range 192.168.0.1 192.168.0.10;
default-lease-time 300;
max-lease-time 300;
next-server 192.168.0.1;
filename "pxelinux.0";
}

pool {
allow unknown clients;
range 192.168.0.11 192.168.0.20;
default-lease-time 21600;
max-lease-time 43200;
}
}

Haven't got any experience with that, are dhcpd and client same (protocol) version?
Isn't the match sposed to be
"match if substring(option vendor-encapsulated-options, 2, 4) = 34:36:39:34;"?
Also you're using the 2nd to 4th first chars, have you tried a wider string, like 0,9?
Else as an alternative, could a match against, say hardware, do the same?

The string I am using to match those four characters/numbers is working correctly. The problem is that the client doesn't send that same information in the DHCPREQUEST, so the server doesn't match those same four characters, thus causing the server to reject the offer. The client is running a PXE boot client. It's in the boot ROM. Unfortunately, I can't do much to change the way it works. I don't understand why the DHCP server isn't matching the transaction ID or hardware address with what it wrote to the dhcpd.conf file when it sent the DHCPOFFER. Even worse is that I had a system board failure that trashed my linux box, so I have to get it rebuilt before I can even continue. Thanks for the reply.

Ok, but wouldn't it then be easier to match the string "PXE Client" as described in the thinclient/bootp/like that howto's?

Yes, it would, but there will be multiple types of clients doing PXE booting, and I want these specific clients to get a different bootstrap.

4.2.2.8. Set vendor_class_identifier
Set the vendor-class-identifier field to PXEClient in the dhcp answer. If this field is not set properly, the PXE client will ignore the answer ! Maybe wide off the mark, but could this explain why it doesn't send back a reply with VCI in it?

The client sends the VCI regardless. Both the DHCPDISCOVER and DHCPREQUEST contain the PXEClient string, but so does every other PXE Client broadcasting DHCPDISCOVER and DHCPREQUEST. The only thing that sets these devices apart from the others is the vendor encapsulated options which are only sent in the DHCPDISCOVER.

Thnx for the clarification. I'll shut up now :-]

I appreciate your help, and I am more than open to suggestions. It seems to me it's a bug in ISC's DHCP server. The server makes the offer to the client, then retracts the offer just because the client doesn't send the same message the second time. I understand why it's failing, but I don't understand why it doesn't look at the dhcpd.leases to see that it just offered that IP address to that MAC address.

Hi everybody, I'm hitting the same problem described in this thread. Maybe in the meantime somebody get the resolution?

Thanks,
Riccardo