I found an interoperability problem with dhclient and bootpd-DD2-4.3 daemon. Everything works well, but dhclient rejects DHCKACK packets without specified time lease. Reply from bootp-DD2 might violate RFC, but infinite lease time works perfectly in this combination and other tested OSes and devices does not have any problem with this bootp but little dhcp modified server. Note that even the current implementation creates a denial attack to server and network because dhclient immediately starts new DHCP session thus many broadcast packets might be generated. This noticably slows down the server and client on 1Gbit network with current hardware. This problem is probably in all dhclient packages. Patch solving problem is attached.
Created attachment 290757 [details] Server response without lease time is equal to infinite (max.) lease time
While the patch you've provided works around the problem you're experiencing, it's not really a good fix. The problem you are describing needs to be fixed in bootpd-DD2-4.3, not dhclient. RFC 2131, section 4.3.1 states that the server must give the client the lease expiration time. If we don't receive that, the DHCP protocol has been broken. The only thing we can reasonably do if the user wants the client to continue running is to re-enter the INIT state. RFC 2131 also does not guarantee that a dhcp client can communicate with a bootp server correctly, only that bootp clients can still get information from dhcp servers. I don't know much about bootpd- DD2-4.3, but it sounds like it's not a compliant DHCP server. DHCP already has far too many known workarounds for different clients and servers. I do not want to add to that list by adding this patch. Please see that this bug is fixed in bootpd if it's to even be fixed. I would reassign to bootparamd, but that doesn't look like the same software you're using.