Bug #41358 for dhcp-public: dhcpd inappropriately frees lease

When a client using option 61 client identifier moves to a new network and obtains a lease, its lease for an IP on the old network is inappropriately freed by dhcpd. Server: isc-dhcpd-4.3.3, compiled with --enable-log-pid --enable-delayed-ack --enable-binary-leases and running on Red Hat 6.7. ip = 128.174.204.220 Client: Peppermint 6 (VM with bridged network adapter) mac = 08:00:27:16:86:31 DHCP client ID = \001\x08\x00\x27\x16\x86\x31 Two networks with DHCP relay pointing to this server. Steps: 1. start dhcpd (with initially empty leases file) 2. attach client to first network, obtain lease 3. disconnect client 4. attach client to second network, obtain lease 5. Observe in leases file that the first lease has been inappropriately freed. ts-dhcp@dhcp-dev1:~$ cat /services/ts-dhcp/etc/dhcpd-test.conf lease-file-name "/services/ts-dhcp/var/lib/dhcpd/dhcpd-test.leases"; log-facility local7; default-lease-time 3600; max-lease-time 3600; min-lease-time 3600; dhcp-cache-threshold 0; # local subnet subnet 128.174.204.0 netmask 255.255.254.0 { not authoritative; } subnet 192.17.12.0 netmask 255.255.255.224 { option routers 192.17.12.1; pool { range 192.17.12.10 192.17.12.20; } } subnet 172.21.195.0 netmask 255.255.255.240 { option routers 172.21.195.1; pool { range 172.21.195.10 172.21.195.14; } } ts-dhcp@dhcp-dev1:~$ rm ~/var/lib/dhcpd/dhcpd-test.leases; touch ~/var/lib/dhcpd/dhcpd-test.leases ts-dhcp@dhcp-dev1:~$ sudo /services/smg-p/bin/dhcpd -f -cf /services/ts-dhcp/etc/dhcpd-test.conf -d Internet Systems Consortium DHCP Server 4.3.3 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /services/ts-dhcp/etc/dhcpd-test.conf Database file: /services/ts-dhcp/var/lib/dhcpd/dhcpd-test.leases PID file: /services/ts-dhcp/var/run/dhcpd.pid Source compiled to use binary-leases Wrote 0 leases to leases file. Listening on LPF/eth0/00:50:56:8c:50:67/128.174.204.0/23 Sending on LPF/eth0/00:50:56:8c:50:67/128.174.204.0/23 Sending on Socket/fallback/fallback-net Server starting service. DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 08:00:27:16:86:31 via 192.17.12.1 DHCPOFFER on 192.17.12.10 to 08:00:27:16:86:31 (p6test1) via 192.17.12.1 DHCPREQUEST for 192.17.12.10 (128.174.204.220) from 08:00:27:16:86:31 (p6test1) via 192.17.12.1 DHCPACK on 192.17.12.10 to 08:00:27:16:86:31 (p6test1) via 192.17.12.1 DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPREQUEST for 192.17.12.10 from 08:00:27:16:86:31 (p6test1) via 172.21.195.1: ignored (not authoritative). DHCPDISCOVER from 08:00:27:16:86:31 via 172.21.195.1 DHCPOFFER on 172.21.195.10 to 08:00:27:16:86:31 (p6test1) via 172.21.195.1 DHCPREQUEST for 172.21.195.10 (128.174.204.220) from 08:00:27:16:86:31 (p6test1) via 172.21.195.1 DHCPACK on 172.21.195.10 to 08:00:27:16:86:31 (p6test1) via 172.21.195.1 DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases DHCPDISCOVER from 00:10:18:72:58:e9 via eth0: network 128.174.204.0/23: no free leases ^C (note: please ignore the lines about 00:10:18:72:58:e9, this is an errant box which happens to live on the locally attached subnet of the server) ts-dhcp@dhcp-dev1:~$ cat ~/var/lib/dhcpd/dhcpd-test.leases # The format of this file is documented in the dhcpd.leases(5) manual page. # This lease file was written by isc-dhcp-4.3.3 server-duid "\000\001\000\001\036\012\371{\000PV\214Pg"; lease 192.17.12.10 { starts 1 2015/12/21 17:55:24; ends 1 2015/12/21 18:55:24; cltt 1 2015/12/21 17:55:24; binding state active; next binding state free; rewind binding state free; hardware ethernet 08:00:27:16:86:31; uid "\001\010\000'\026\2061"; client-hostname "p6test1"; } lease 192.17.12.10 { starts 1 2015/12/21 17:55:24; ends 1 2015/12/21 17:56:28; tstp 1 2015/12/21 17:56:28; cltt 1 2015/12/21 17:55:24; binding state free; hardware ethernet 08:00:27:16:86:31; uid "\001\010\000'\026\2061"; } lease 172.21.195.10 { starts 1 2015/12/21 17:56:29; ends 1 2015/12/21 18:56:29; cltt 1 2015/12/21 17:56:29; binding state active; next binding state free; rewind binding state free; hardware ethernet 08:00:27:16:86:31; uid "\001\010\000'\026\2061"; client-hostname "p6test1"; } Note that the bug does *not* appear (i.e. lease 192.17.12.10 remains active, as it should) if the client does not send option 61. I've attached a packet capture (from the server) containing the nine relevant packets. -- David Zych Lead Network Service Engineer University of Illinois Technology Services

---

On 09/23/2016 09:29 AM, Thomas Markwalder via RT wrote: > I've attached a patch which should correct this issue for you, if you have time to test it, your feedback would be most welcome. This patch (applied to 4.3.4) does indeed appear to resolve the problem for my test case. FWIW, having now perused the affected section of code, I think there is a simpler alternative patch (attached) which improves rather than lessens the overall symmetry between the blocks enclosed by while (uid_lease) { ... } and while (hw_lease) { ... } > You're taking the time to include detailed information and packet traces is greatly appreciated. We typically like to thank our contributors by citing them in the release notes. If you would like to be recognized in this way plesae let me know how you care to be identified. Typically it's by name and/or organization. David Zych at University of Illinois Thanks! David

---