We need to engineer a replacement to the Unbound DHCP Leases Bridge. Since that has always been an utter ball ache, we will need to replace this with another solution which currently is unknown.
I have pushed a couple of changes that are supposed to implement this now. Instead of parsing the lease file, the DHCP server will call a script to store all leases in a sqlite3 database which will be queried by kresd through a custom policy module: > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=76449e1bb4b9053064f5115b00f1b018da77c9e2 > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=4e65f4205ef63b738f00b8218787e746c913da00 > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=23ed84bc473134f4101a58e47723b347b12ca6c5 > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=6b75593cbdce1bba18e7c667d699cf78cb154dc3 The module uses a simple print() statement for logging which will need to be replaced by proper logging as soon as it has been verified that this approach is workable.
https://www.ipfire.org/blog/ipfire-2-29-core-update-203-is-available-for-testing
I don't think this is resoled yet. At least for me. I have a few DHCP dynamic leases, for example: IP address MAC Address Hostname Lease expires (local time d/m/y) 192.168.50.12 ac:3e:00:00:00:00 Pixel-7 12/06/2026 12:20:23 192.168.50.59 f8:17:00:00:00:00 wlan0 12/06/2026 12:41:17 But if I try to lookup or reverse lookup I get NXDOMAIN for both: # nslookup 192.168.50.12 ** server can't find 12.50.168.192.in-addr.arpa: NXDOMAIN # nslookup 192.168.50.59 ** server can't find 59.50.168.192.in-addr.arpa: NXDOMAIN # nslookup Pixel-7.ocean.home Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find Pixel-7.ocean.home: NXDOMAIN # nslookup wlan0.ocean.home Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find wlan0.ocean.home: NXDOMAIN For me it doesn't look like DHCP leases are resolving correctly. I've had the same results on both GREEN and BLUE. This doesn't affect manually defined hosts, they appear to be working correctly. Tested locally using build next/e18915cb
Could you check for me if the leases database holds the correct data? That way we know whether dhcpd fails to put the data into the database, or Knot Resolver is unable to fetch the data from it.
I checked the leases DB it only contains the two entries I manually added for testing: 192.168.0.250 kres-test.forest.home. 192.168.50.13 pixel-tablet.ocean.home I don’t see normal DHCP leases being added to the DB. The dhcpd hook is being called, but it fails. For example this matches what dhcpd is passing: /usr/sbin/dhcp-lease commit ADDRESS=192.168.50.13 NAME=Pixel-Tablet and it fails with: Missing HOSTNAME= exit=2 This works: /usr/sbin/dhcp-lease commit ADDRESS=192.168.50.13 HOSTNAME=Pixel-Tablet DOMAINNAME=ocean.home and exits with 0. I also checked /etc/dhcp/dhcpd.conf. The subnet domains look right: GREEN -> Forest.home BLUE -> Ocean.home but the hook still calls dhcp-lease with NAME= and no DOMAINNAME=. So I think dhcpd is calling dhcp-lease, but dhcp-lease rejects the arguments The log summary also matches this: execute: /usr/sbin/dhcp-lease exit status 512: 499 Time(s) I don't know if this is just a "me thing" due to messing around too much. I might just need a fresh install...
Also some entries of DHCP server in log summery some still mentioning Unbound: Unknown Entries: Unable to execute /usr/sbin/unbound-dhcp-leases-client: No such file or directory: 1 Time(s) execute: /usr/sbin/dhcp-lease exit status 512: 499 Time(s) execute: /usr/sbin/unbound-dhcp-leases-client exit status 32512: 1 Time(s) execute_statement argv[0] = /usr/sbin/dhcp-lease: 502 Time(s) execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client: 1 Time(s) execute_statement argv[1] = commit: 499 Time(s) execute_statement argv[1] = expiry: 4 Time(s) execute_statement argv[2] = ADDRESS=192.168.0.182: 2 Time(s) execute_statement argv[2] = ADDRESS=192.168.0.2: 2 Time(s) execute_statement argv[2] = ADDRESS=192.168.0.3: 2 Time(s) execute_statement argv[2] = ADDRESS=192.168.0.8: 2 Time(s) execute_statement argv[2] = ADDRESS=192.168.0.9: 2 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.10: 48 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.12: 24 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.13: 56 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.14: 27 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.59: 302 Time(s) execute_statement argv[2] = ADDRESS=192.168.50.60: 36 Time(s)
Core Update 203 has been released: > https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released
I get proper static dhcp leases and /etc/dhcp/dhcpd.conf looks valid but most of my clients don't get their hostnames registered with core 203 now. For some clients the log looks ok: 12:05:21 dhcpd: DHCPACK on 192.168.1.13 to XX:XX:XX:XX:XX:XX via green0 12:05:21 dhcpd: DHCPREQUEST for 192.168.1.13 from XX:XX:XX:XX:XX:XX via green0 12:05:21 dhcpd: execute_statement argv[4] = DOMAINNAME=internal 12:05:21 dhcpd: execute_statement argv[3] = HOSTNAME=SAMSUNG-PRINTER 12:05:21 dhcpd: execute_statement argv[2] = ADDRESS=192.168.1.13 12:05:21 dhcpd: execute_statement argv[1] = commit 12:05:21 dhcpd: execute_statement argv[0] = /usr/sbin/dhcp-lease for others registering fails: 12:03:39 dhcpd: DHCPACK on 192.168.1.3 to XX:XX:XX:XX:XX:XX via green0 12:03:39 dhcpd: DHCPREQUEST for 192.168.1.3 (192.168.1.1) from XX:XX:XX:XX:XX:XX via green0 12:03:39 dhcpd: execute: /usr/sbin/dhcp-lease exit status 512 12:03:39 dhcpd: execute_statement argv[4] = DOMAINNAME=internal 12:03:39 dhcpd: execute_statement argv[3] = HOSTNAME= 12:03:39 dhcpd: execute_statement argv[2] = ADDRESS=192.168.1.3 12:03:39 dhcpd: execute_statement argv[1] = commit 12:03:39 dhcpd: execute_statement argv[0] = /usr/sbin/dhcp-lease 12:03:39 dhcpd: DHCPOFFER on 192.168.1.3 to XX:XX:XX:XX:XX:XX via green0 12:03:39 dhcpd: DHCPDISCOVER from XX:XX:XX:XX:XX:XX via green0 It seems not related whether there's only on MAC registered or 2 MACs (Wifi+ETH) for one client IP. Adding the desired hostnames to "Edit hosts" page makes them reachable in the LAN. I suggest to reopen this issue.