CU203 Test : dhcp entries not resolving

Installing & Running IPFire Testing
1

I have the same issue of

To whom no one replied

DHCP hosts are not registered in knot-resolver (static and dynamic).

Here is the extract from /var/ipfire/dhcp/dhcpd.conf

deny bootp;	#default
authoritative;
ddns-update-style none;
option wpad code 252=text;

subnet 192.168.20.0 netmask 255.255.255.0 #GREEN
{
pool {
	range 192.168.20.203 192.168.20.208;
     }
	option subnet-mask 255.255.255.0;
	option domain-name "pshome";
	option routers 192.168.20.1;
	option domain-name-servers 192.168.20.1;
	option ntp-servers 192.168.20.1;
	default-lease-time 3600;
	max-lease-time 7200;
	option wpad "http://192.168.20.1:81/proxy.pac";
} #GREEN

on commit {
	set ClientAddress = concat(
		"ADDRESS=",
		binary-to-ascii(10, 8, ".", leased-address)
	);
	set ClientName = concat(
		"NAME=",
		pick-first-value(option host-name, config-option-host-name, client-name, "")
	);

	if (ClientName != "") {
		execute("/usr/sbin/dhcp-lease", "commit", ClientAddress, ClientName);
	}
}
...

host fix71 # virtual11
{
	hardware ethernet 00:0c:29:43:5e:1a;
	fixed-address 192.168.20.9;
}

Here is the extract /var/log/messages

Jul 10 13:05:31 ipfireSec dhcpd: execute_statement argv[0] = /usr/sbin/dhcp-lease
Jul 10 13:05:31 ipfireSec dhcpd: execute_statement argv[1] = commit
Jul 10 13:05:31 ipfireSec dhcpd: execute_statement argv[2] = ADDRESS=192.168.20.9
Jul 10 13:05:31 ipfireSec dhcpd: execute_statement argv[3] = NAME=virtual11
Jul 10 13:05:31 ipfireSec dhcpd: execute: /usr/sbin/dhcp-lease exit status 512
Jul 10 13:05:31 ipfireSec dhcpd: DHCPREQUEST for 192.168.20.9 from 00:0c:29:43:5e:1a via green0
Jul 10 13:05:31 ipfireSec dhcpd: DHCPACK on 192.168.20.9 to 00:0c:29:43:5e:1a via green0

Here is the debug trace of /usr/sbin/dhcp-lease (set -x)

[dhcp-lease:7] readonly DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:7] DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:131] main commit ADDRESS=192.168.20.9 NAME=virtual11
[dhcp-lease:11] '[' '!' -f /var/lib/knot-resolver/leases.db ']'
[dhcp-lease:19] local action=commit
[dhcp-lease:20] shift
[dhcp-lease:22] case "${action}" in
[dhcp-lease:24] local address
[dhcp-lease:25] local hostname
[dhcp-lease:26] local domainname
[dhcp-lease:28] '[' 2 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:31] address=192.168.20.9
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 1 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 0 -gt 0 ']'
[dhcp-lease:47] '[' -z 192.168.20.9 ']'
[dhcp-lease:50] '[' -z '' ']'
[dhcp-lease:51] echo '/usr/sbin/dhcp-lease: Missing HOSTNAME='
[dhcp-lease:52] return 2
[dhcp-lease:131] exit 2

The same applies to the dynamic address.

Here is the extract /var/log/messages

Jul 10 13:18:56 ipfireSec dhcpd: DHCPOFFER on 192.168.20.205 to 00:0c:29:86:74:c9 (linuxmint) via green0
Jul 10 13:18:56 ipfireSec dhcpd: execute_statement argv[0] = /usr/sbin/dhcp-lease
Jul 10 13:18:56 ipfireSec dhcpd: execute_statement argv[1] = commit
Jul 10 13:18:56 ipfireSec dhcpd: execute_statement argv[2] = ADDRESS=192.168.20.205
Jul 10 13:18:56 ipfireSec dhcpd: execute_statement argv[3] = NAME=linuxmint
Jul 10 13:18:56 ipfireSec dhcpd: execute: /usr/sbin/dhcp-lease exit status 512
Jul 10 13:18:56 ipfireSec dhcpd: DHCPREQUEST for 192.168.20.205 (192.168.20.1) from 00:0c:29:86:74:c9 (linuxmint) via green0
Jul 10 13:18:56 ipfireSec dhcpd: Wrote 0 deleted host decls to leases file.
Jul 10 13:18:56 ipfireSec dhcpd: Wrote 0 new dynamic host decls to leases file.
Jul 10 13:18:56 ipfireSec dhcpd: Wrote 4 leases to leases file.
Jul 10 13:18:56 ipfireSec dhcpd: DHCPACK on 192.168.20.205 to 00:0c:29:86:74:c9 (linuxmint) via green0

Here is the debug trace of /usr/sbin/dhcp-lease (set -x)

[dhcp-lease:7] readonly DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:7] DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:131] main commit ADDRESS=192.168.20.205 NAME=linuxmint
[dhcp-lease:11] '[' '!' -f /var/lib/knot-resolver/leases.db ']'
[dhcp-lease:19] local action=commit
[dhcp-lease:20] shift
[dhcp-lease:22] case "${action}" in
[dhcp-lease:24] local address
[dhcp-lease:25] local hostname
[dhcp-lease:26] local domainname
[dhcp-lease:28] '[' 2 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:31] address=192.168.20.205
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 1 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 0 -gt 0 ']'
[dhcp-lease:47] '[' -z 192.168.20.205 ']'
[dhcp-lease:50] '[' -z '' ']'
[dhcp-lease:51] echo '/usr/sbin/dhcp-lease: Missing HOSTNAME='
[dhcp-lease:52] return 2
[dhcp-lease:131] exit 2

on the virtual11 side (windows 11)

PS C:\Users\user> nslookup linuxmint
Serveur :   ipfire.pshome
Address:  192.168.20.1

*** ipfire.pshome ne parvient pas à trouver linuxmint : Non-existent domain
PS C:\Users\user>

PS C:\Users\user> ping 192.168.20.205

Envoi d’une requête 'Ping'  192.168.20.205 avec 32 octets de données :
Réponse de 192.168.20.205 : octets=32 temps<1ms TTL=64
Réponse de 192.168.20.205 : octets=32 temps<1ms TTL=64
Réponse de 192.168.20.205 : octets=32 temps<1ms TTL=64

Statistiques Ping pour 192.168.20.205:
    Paquets : envoyés = 3, reçus = 3, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms

on the linuxmint side (Linux Mint)

phili@linuxmint:~$ nslookup virtual11
;; Got SERVFAIL reply from 127.0.0.53
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find virtual11: SERVFAIL

phili@linuxmint:~$ ping 192.168.20.9
PING 192.168.20.9 (192.168.20.9) 56(84) bytes of data.
64 bytes from 192.168.20.9: icmp_seq=1 ttl=128 time=0.363 ms
64 bytes from 192.168.20.9: icmp_seq=2 ttl=128 time=0.449 ms
64 bytes from 192.168.20.9: icmp_seq=3 ttl=128 time=0.455 ms
64 bytes from 192.168.20.9: icmp_seq=4 ttl=128 time=0.419 ms
^C
--- 192.168.20.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3050ms
rtt min/avg/max/mdev = 0.363/0.421/0.455/0.036 ms
2

Hi Phil.

I had this same issue but I resolved it by disabling Green and Blue DHCP (untick both) then press save. Then re-enabling both (or whichever needed)

Can you test this and report back with the results?

Thanks,
A G

3

Thanks !

This solution works.

Here is the debug trace of /usr/sbin/dhcp-lease (set -x) OK

[dhcp-lease:7] readonly DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:7] DB_PATH=/var/lib/knot-resolver/leases.db
[dhcp-lease:131] main commit ADDRESS=192.168.20.9 HOSTNAME=virtual11 DOMAINNAME=pshome
[dhcp-lease:11] '[' '!' -f /var/lib/knot-resolver/leases.db ']'
[dhcp-lease:19] local action=commit
[dhcp-lease:20] shift
[dhcp-lease:22] case "${action}" in
[dhcp-lease:24] local address
[dhcp-lease:25] local hostname
[dhcp-lease:26] local domainname
[dhcp-lease:28] '[' 3 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:31] address=192.168.20.9
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 2 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:34] hostname=virtual11
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 1 -gt 0 ']'
[dhcp-lease:29] case "${1}" in
[dhcp-lease:37] domainname=pshome
[dhcp-lease:43] shift
[dhcp-lease:28] '[' 0 -gt 0 ']'
[dhcp-lease:47] '[' -z 192.168.20.9 ']'
[dhcp-lease:50] '[' -z virtual11 ']'
[dhcp-lease:53] '[' -z pshome ']'
[dhcp-lease:58] [[ virtual11 =~ ^[A-Za-z0-9_-]{1,63}$ ]]
[dhcp-lease:64] hostname=virtual11.pshome.
[dhcp-lease:67] hostname=virtual11.pshome.
[dhcp-lease:69] sqlite3 /var/lib/knot-resolver/leases.db
[dhcp-lease:128] return 0

on the virtual11 side (windows 11)

PS C:\Users\user> nslookup linuxmint
Serveur :   wpad.pshome
Address:  192.168.20.1

Nom :    linuxmint.pshome
Address:  192.168.20.205

on the linuxmint side (Linux Mint)

phili@linuxmint:~$ nslookup virtual11.pshome
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	virtual11.pshome
Address: 192.168.20.9
** server can't find virtual11.pshome: NXDOMAIN

It’s an issue in the Update ?

4

I had the issue with the backup/restore

But I didn’t think of that solution involving the update.

5

Yes, I think this is probably an issue with the CU migration.

It appears that the update installed the new /usr/sbin/dhcp-lease script, which expects arguments in this form (using your example):

ADDRESS=192.168.20.9
HOSTNAME=virtual11
DOMAINNAME=pshome

However, the existing generated DHCP configuration was still using the older:

NAME=virtual11

Because the new script does not recognise NAME=, it reported Missing HOSTNAME= and exited with status 2.

Disabling DHCP, saving, and then enabling it again causes IPFire to regenerate a DHCP configuration using the new template. Your new “set -x” trace now shows the correct arguments, the SQLite update succeeds, and the script returns 0.

It also makes sense why restoring a backup would also have a similar issue.

Thanks,
A G

6

Here is a comparison of the /var/ipfire/dhcp.conf files:

1 - Version OK after reloading dhcp.cgi page
2 - Version KO after CU202 → CU203 upgrade
3 - Version KO after restoring CU202 backup onto CU203

Capture d’écran 2026-07-10 170958
Capture d’écran 2026-07-10 1709582410×742 323 KB

7

@pscar13 , thanks for your detailed description.

It shows the general problem of upgrade/backup processes when modifications to the config files / worker programs are made.
The updated SW collection is consistent regarding this change, I checked especially for dhcp.cgi NAME<-->HOSTNAME conflict, but a restore of old states destroys this.
Because IPFire follows the process do the configuration in the WUI → a ‘save’ builds the config files this problem can’t be handled automagically without some effort. The process

  • upgrade
  • backup
  • possible problems try to resolve by saving the config again

My opion.

BTW, looking into the open sources helps much.

8

Thanks, @bbitsch.

No worries; I have no problem reading the IPFire source code.

I understand that the files /config/rootfiles/core/203/update.sh and /config/backup/backup.pl are both affected.

I also understand that this is a complex change and that the migration from Unbound to Knot Resolver cannot be handled automatically in every scenario.

My intention is not to tell the developers how this implementation should be carried out, but simply to share the information.

Here is a workaround for dhcp.conf.
@ag has already reported a bug related to this issue.

If the programs involved cannot be adapted, users encountering the same problem will at least be able to find this information.

9

I did not think of these two files for identifying the issue.

Where are they? No topic in bugzilla and no post in the dev list (as far I remember).

Isn’t my ‘simple workaround ( just click save )’ working?

10

The reported bug is here.

The workaround for dhcp.conf was provided here.

Indeed, clicking “Save” should be enough.

Edit : Anyway, thank you both for taking the time to get back to me.

11

Just about the bugzilla post. Last topic is dated June, 12. There were some updates since then.
And @ag didn’t mention a save operation to generate a compatible dhcp.conf and doesn’t reflect to the sources, which are the main topic.