| Summary: | Web UI and /var/lib/knot-resolver/leases.db mismatch | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | barneyklarnocks <ben> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | - Unknown - | CC: | adolf.belka, andreas.radke, bbitsch, michael.tremer, paul.lipinski |
| Version: | 2 | ||
| Hardware: | x86_64 | ||
| OS: | Other | ||
| Attachments: |
A screenshot of part of the "Network" > "DHCP Server" page on the IPFire Web UI.
The output of "grep dhcpd /var/log/messages" |
||
|
Description
barneyklarnocks
2026-07-28 13:34:49 UTC
Typo: "recurrent" > "recurred" Hello Barney, do you have the output of "grep dhcpd /var/log/messages" for me? DNS relies on the DHCP server updating any entries and we need to check if there has been an update issued. I do, going back to midnight of 26 July. I logged this issue on 28 July. It's just 626 lines. I'll attached the whole thing as a gzipped tarball. One sec... Created attachment 1737 [details]
The output of "grep dhcpd /var/log/messages"
Attached.
I believe I have a concrete reproduction of the issue described in this bug, including evidence of what appears to be the underlying cause. My system is running: IPFire 2.29 (x86_64) Core Update 203 isc-dhcpd 4.4.3-P1 I have a Linux VM named "ghost" with MAC address: bc:24:11:7e:95:b8 The VM initially received 192.168.1.222 via DHCP. IPFire's DHCP log shows: Oct 1 20:40:32 router dhcpd: DHCPOFFER on 192.168.1.222 to bc:24:11:7e:95:b8 (ghost) via green0 Oct 1 20:40:32 router dhcpd: DHCPREQUEST for 192.168.1.222 (192.168.1.1) from bc:24:11:7e:95:b8 (ghost) via green0 Oct 1 20:40:32 router dhcpd: DHCPACK on 192.168.1.222 to bc:24:11:7e:95:b8 (ghost) via green0 At that point, dhcp-lease created the expected Knot Resolver lease: 192.168.1.222 | ghost.lan. Later, the VM's network interface was restarted. It then received its configured fixed address, 192.168.1.212: Oct 1 21:32:53 router dhcpd: DHCPOFFER on 192.168.1.212 to bc:24:11:7e:95:b8 (ghost) via green0 Oct 1 21:32:53 router dhcpd: DHCPREQUEST for 192.168.1.212 (192.168.1.1) from bc:24:11:7e:95:b8 (ghost) via green0 Oct 1 21:32:53 router dhcpd: DHCPACK on 192.168.1.212 to bc:24:11:7e:95:b8 (ghost) via green0 Therefore DHCP itself successfully changed the client's address, and the hostname remained "ghost". However, /var/lib/knot-resolver/leases.db continued to contain: 192.168.1.222 | ghost.lan. There was no: 192.168.1.212 | ghost.lan. entry. Consequently, DNS continued returning: ghost.lan -> 192.168.1.222 even though the DHCP client was actually using 192.168.1.212. I manually deleted the stale .222 row from leases.db and renewed the DHCP lease. After that, the .212 | ghost.lan. entry was successfully created and DNS immediately returned .212. I inspected /usr/sbin/dhcp-lease and the leases database schema. The table has a unique hostname index: CREATE UNIQUE INDEX leases_hostname ON leases(hostname COLLATE NOCASE); However, the commit operation performs an UPSERT based only on the address: INSERT INTO leases(address, hostname) VALUES (:address, :hostname) ON CONFLICT(address) DO UPDATE SET hostname = excluded.hostname; This appears to create a problem when a hostname moves from one address to another. For example, if the database contains: 192.168.1.222 | ghost.lan. and DHCP subsequently commits: 192.168.1.212 | ghost.lan. the address does not conflict, so the ON CONFLICT(address) clause does not apply. SQLite instead attempts to insert a second ghost.lan. row, which conflicts with the unique hostname index. The old row therefore remains and the new row is not created. The script also does not appear to check/propagate the exit status of the SQLite operation in the commit path, so this failure can occur without an obvious DHCP error. The important distinction in this case is that the DHCP server did issue the address/hostname update. The DHCP log proves the same client/hostname moved: 192.168.1.222 -> ghost 192.168.1.212 -> ghost The failure appears to occur specifically while synchronizing that change into: /var/lib/knot-resolver/leases.db This also seems to explain the observed Web UI/DNS/database mismatch described in this bug. A possible fix would be for dhcp-lease commit to remove an existing entry for the same hostname at another address before inserting/updating the new address, or otherwise perform an UPSERT based on hostname as well as address. For example, conceptually: BEGIN; DELETE FROM leases WHERE hostname = :hostname AND address != :address; INSERT INTO leases(address, hostname) VALUES (:address, :hostname) ON CONFLICT(address) DO UPDATE SET hostname = excluded.hostname; COMMIT; The SQLite return status should also be checked so that a failed database update is not silently reported as successful. |