Bug 13973

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.