Hi Thomas, I like your parameter solution very much, and I confirm that the patch successfully prevents the problem scenarios I originally reported -- thanks! However, there's a variant scenario whose behavior still seems wrong: Single DHCP server with a clean-slate lease file and the following config: === subnet 128.174.204.0 netmask 255.255.254.0 { not authoritative; } lease-file-name "/services/ts-dhcp/var/lib/dhcpd/dhcpd.leases"; log-facility local7; ping-check true; ping-timeout 1; subnet 172.21.195.0 netmask 255.255.255.240 { option routers 172.21.195.1; option broadcast-address 172.21.195.15; pool { deny dynamic bootp clients; range 172.21.195.13 172.21.195.14; } } === plus two "squatter" VMs occupying both IP addresses, and a single Peppermint 6 client VM attempting to obtain a lease via DHCP (booting from a snapshot with no prior state on this network)... Both IPs are correctly abandoned (and remain correctly abandoned) due to the ICMP replies, and no DHCPOFFER is made. Additionally, they remain correctly abandoned across a dhcpd restart. However, if we now remove the 172.21.195.14 squatter from the test network (which in principle should make it possible to *successfully* reclaim that lease and give it to the DHCP client), we instead observe: 2016-07-11T15:01:11.212293-05:00 dhcp-dev1 dhcpd.20160707[27959]: Reclaiming abandoned lease 172.21.195.13. 2016-07-11T15:01:11.212308-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPDISCOVER from 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:11.212713-05:00 dhcp-dev1 dhcpd.20160707[27959]: ICMP Echo reply while lease 172.21.195.13 valid. 2016-07-11T15:01:11.212719-05:00 dhcp-dev1 dhcpd.20160707[27959]: Abandoning IP address 172.21.195.13: pinged before offer 2016-07-11T15:01:24.774305-05:00 dhcp-dev1 dhcpd.20160707[27959]: Reclaiming abandoned lease 172.21.195.14. 2016-07-11T15:01:24.774330-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPDISCOVER from 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:25.775425-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPOFFER on 172.21.195.14 to 08:00:27:64:2f:26 (p6test3) via 172.21.195.1 2016-07-11T15:01:25.779128-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:25.779134-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:28.976453-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:28.976479-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:35.563721-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:35.563735-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:42.084304-05:00 dhcp-dev1 dhcpd.20160707[27959]: Reclaiming abandoned lease 172.21.195.14. 2016-07-11T15:01:42.084323-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPDISCOVER from 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:43.085405-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPOFFER on 172.21.195.14 to 08:00:27:64:2f:26 (p6test3) via 172.21.195.1 2016-07-11T15:01:43.088356-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:43.088368-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:46.849568-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:46.849593-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:01:50.422391-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:01:50.422414-05:00 dhcp-dev1 dhcpd.20160707[27959]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 ... Somehow dhcpd is of two different minds about the status of .14 -- it has correctly determined that it's now okay to OFFER the lease, but refuses to ACK the client's request for it. The other odd thing is that, if I repeat this experiment from the beginning with "abandon-lease-time 180;" added to the config, the abandoned lease 172.21.195.14 is not cleared three minutes after the last time a ping-check resulted in an ICMP reply (which is what I expected). Instead, this lease remains abandoned (and continues to behave in the OFFER-but-NAK mode described above) for as long as the DHCP client keeps trying to get it, and is cleared only after the client gives up and 2 more minutes elapse. * last failed ping-check while squatter was still active: 2016-07-11T15:13:27.410532-05:00 dhcp-dev1 dhcpd.20160707[28315]: ICMP Echo reply while lease 172.21.195.14 valid. 2016-07-11T15:13:27.410539-05:00 dhcp-dev1 dhcpd.20160707[28315]: Abandoning IP address 172.21.195.14: pinged before offer * resulting lease entry: lease 172.21.195.14 { starts 1 2016/07/11 20:13:27; ends 1 2016/07/11 20:16:27; cltt 1 2016/07/11 20:13:27; binding state abandoned; next binding state free; rewind binding state free; client-hostname "p6test3"; } * last OFFER-but-NAK occurrence: 2016-07-11T15:18:34.334342-05:00 dhcp-dev1 dhcpd.20160707[28315]: Reclaiming abandoned lease 172.21.195.14. 2016-07-11T15:18:34.334361-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPDISCOVER from 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:18:35.335426-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPOFFER on 172.21.195.14 to 08:00:27:64:2f:26 (p6test3) via 172.21.195.1 2016-07-11T15:18:35.338290-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:18:35.338296-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:18:39.054633-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:18:39.054654-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 2016-07-11T15:18:42.214211-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPREQUEST for 172.21.195.14 (128.174.204.220) from 08:00:27:64:2f:26 via 172.21.195.1: lease 172.21.195.14 unavailable. 2016-07-11T15:18:42.214230-05:00 dhcp-dev1 dhcpd.20160707[28315]: DHCPNAK on 172.21.195.14 to 08:00:27:64:2f:26 via 172.21.195.1 * resulting lease entry (written at UTC 20:20:34, not 20:18:34): lease 172.21.195.14 { starts 1 2016/07/11 20:18:34; ends 1 2016/07/11 20:20:34; cltt 1 2016/07/11 20:18:34; binding state free; hardware ethernet 08:00:27:64:2f:26; client-hostname "p6test3"; } After this, if the client returns again, it has no problem obtaining the now-free lease. So this remaining scenario should AFAICT only impact nets which become completely full. Thanks, David P.S. My test dhcpd (dhcp-4.3.4 with rt41815.patch) was compiled with --prefix=... --sysconfdir=... --localstatedir=... \ --enable-log-pid --enable-delayed-ack --enable-binary-leases --enable-use-sockets, just in case any of that matters (though I doubt it should). > Lastly, it is our custom to thank our contributors by citing them in the release notes. If you would like be recognized in this fashion please reply with how you would like to be identified. Most often, it is by name and/or organization. David Zych at University of Illinois Thanks! David -- David Zych Lead Network Service Engineer University of Illinois Technology Services