DHCP in update 200 seems to be working OK for me on Red, Blue and Green, but I noticed an error in /var/log/messages that might need some attention:
dhcp[4080]: Callback failed: ‘UnboundDHCPLeasesBridge’ object has no attribute ‘hosts’ Traceback (most recent call last): File “/usr/sbin/unbound-dhcp-leases-bridge”, line 477, in run self.callback(message) File “/usr/sbin/unbound-dhcp-leases-bridge”, line 228, in _handle_message self._add_lease(lease) File “/usr/sbin/unbound-dhcp-leases-bridge”, line 293, in _add_lease elif lease.fqdn in self.hosts: AttributeError: ‘UnboundDHCPLeasesBridge’ object has no attribute ‘hosts’
Looking at the unbound-dhcp-leases-bridge code and the line numbers referenced I am wondering if you have the Hosts WUI page (Menu item Network - Edit Hosts) empty of any entries.
It might be that the code is expecting some entry and therefore if the hosts list is empty then there is no host attribute. However that is more of a guess on my part and I could be completely wrong.
Could you confirm if you have any entries in the Edit Hosts WUI page?
I also found this message in my logs, the earliest of which dates back to January 8th, which could have started after the CU199 update.
This error occurs on reboot, apparently when DHCP connections are established between the end of the dhcpd startup and the start of unbound.
My previous comment about not seeing the message was based on just looking at the logs for all of March 2026.
I have now looked in the logs for February 2026 back to September 2025 and have not found that message or anything similar ( I searched for Callback) in that period. I would definitely have rebooted multiple times in that period.
So there has to be some other additional difference that makes that message occur during booting.
If I remember correctly, you declare your DHCP fixedleases addresses in the hosts file.
On my systems, fixedlease addresses are only declared in DHCP, and only my static addresses are declared in the hosts file, never both.
That might be a clue.
My hosts file isn’t empty.
Edit : The error does not occur on every restart
And it doesn’t pose any particular problem, except for the message
Yes, you are correct I have all my fixed leases listed on the Hosts WUI page.
I have no static addresses used at all.
The only dynamic leases are on the Blue network for when I have visitors.
There is probably some interaction effect dependent on the exact setup.
From the original poster it looks like all clients are able to work okay despite that message so maybe it occurs at booting but is able to be successfully carried out after some time has gone past.
To answer your question: on an old installation (update 193) that doesn’t have any DHCP server problems (or UnboundDHCPLeasesBridge error) there are no entries on the Network > Hosts WUI page. However, there are two fixed leases listed on the Network > DHCP Server WUI page that are working properly.
On a fresh install of 200, I was too quick to declare that the DHCP server was working properly on Blue and Green; it is not. However, the DHCP client is working properly on Red.
I just tried booting up the new (200) installation again. The Unbound error did not occur. Same as Phil, perhaps. And the fixed leases on Green and Blue are being properly issued.
These are two completely separate programs. The DHCP Client that is used on the red connection is called dhcpc.
The DHCP Server used for serving IP’s to any system,s on the green and blue networks is called dhcp.
These two programs are developed by two independent groups of developers.
When you say that the dhcp server is not working properly on green and blue and is not issuing fixed leases, I am not sure that has anything to do with the unbound-dhcp-leases-bridge program.
The provision of a fixed lease IP will be carried out between the dhcp client on your PC’s and the dhcp server on IPFire. It will just provide an IP which enables the network connection to be made.
The unbound-dhcp-leases-bridge software enables the hostname for each client to be linked to the IP so that when a command uses the fqdn for that client it gets correctly converted to the IP and the traffic can then be sent to the right location.
When you say that dhcp on green and blue is not working is the problem that your clients fail to receive their fixed IP or was the problem that when trying to access those clients from another client using the fqdn the resolution of that to the correct IP was failing or was the problem something else entirely?
The former. The most consequential problem is there is a device (a TV tuner) on my LAN (Green) that relies on DHCP. It has no way to assign itself a static IP address.
Could it be that the UnboundDHCPLeasesBridge error is just a side effect of dhcpd not running?
The issues I encountered above are not repeatable. After about half a dozen reboots, they haven’t shown up again. I’ll be keeping an eye out for a recurrence.
@Adolf: Thank you for the explanation of what UnboundDHCPLeasesBridge does.
This does not preclude the possibility that this error is related to a bug in the unbound-dhcp-leases-bridge program.
The hosts variable is sometimes not initialized during the first address assignment after running dhcpd.
dhcpd is started first before the unbound-dhcp-leases-bridge is started.
The provision of an IP to the client is, from my understanding, purely a dhcpd activity so if that function is due to dhcpd not running I would expect to see in the logs some messages about dhcp failing to start but the OP only had the message AttributeError: ‘UnboundDHCPLeasesBridge’ object has no attribute ‘hosts’
That would suggest to me that the dhcp server was successfully started.
I would then look in the dhcp system logs for the date when the client failed to get its IP and search for messages related to the mac address for that client that was failing and see where in the provision of the IP the process stopped.
I would also look in the logs of the client machine’s dhcp client to see what that shows.
That combination of logs should show at which point and from which end the problem was occurring.
So I tested out with the initial default value of hosts which is empty.
There was no problem with starting dhcpd or unbound-dhcp-leases-bridge.
I then removed the hosts file completely so that it didn’t exist.
Rebooted IPFire and no problem occurred.
The hosts file was still missing but both dhcpd or unbound-dhcp-leases-bridge started without issues.
I refreshed the Hosts page in the WUI and no error message was created. The hosts file still was missing.
I then created a host definition in the WUI Hosts page and it created it and also created the hosts file with the host definition in it.
No error messages from dhcpd or unbound-dhcp-leases-bridge.
I am unable to figure out or reproduce getting that AttributeError: ‘UnboundDHCPLeasesBridge’ object has no attribute ‘hosts’
error message or any Callback failded message.
I think we need to understand the specific conditions to reproduce to make it occur but as it does not seem to occur consistently then that will probably be a challenge.
Intermittent problems always are a challenge to fault find.
Only thing I can think of, as it occurs at booting time, is that there is some sort of race condition occurring with some variables.
I added the -vv option to DHCP startup for better visibility. loadproc /usr/sbin/unbound-dhcp-leases-bridge -d -vv
Observing this morning’s startup, I didn’t get any errors
But I noticed that there’s more than one second between dhcpd starting and reading the hosts file.
There could very well be a DHCP assignment request between these two processes…
Mar 30 07:14:13 ipfire dhcpd: Server starting service.
Mar 30 07:14:13 ipfire dhcp[24868]: Unbound DHCP Leases Bridge started on /var/state/dhcp/dhcpd.leases
Mar 30 07:14:13 ipfire dhcp[24868]: Worker 24872 launched
Mar 30 07:14:13 ipfire dhcp[24868]: Watcher launched
Mar 30 07:14:13 ipfire sshd[24881]: Server listening on 0.0.0.0 port 222.
Mar 30 07:14:13 ipfire kernel: IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
Mar 30 07:14:13 ipfire kernel: IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
Mar 30 07:14:13 ipfire kernel: IPVS: ipvs loaded.
Mar 30 07:14:13 ipfire Keepalived[24947]: Starting Keepalived v2.3.1 (05/24,2024)
Mar 30 07:14:13 ipfire Keepalived[24947]: Running on Linux 6.18.7-ipfire #1 SMP PREEMPT_DYNAMIC Tue Feb 24 14:01:17 GMT 2026 (built for Linux 6.12.58)
Mar 30 07:14:13 ipfire Keepalived[24947]: Command line: '/usr/sbin/keepalived'
Mar 30 07:14:13 ipfire Keepalived[24947]: Configuration file /etc/keepalived/keepalived.conf
Mar 30 07:14:13 ipfire Keepalived[24948]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
Mar 30 07:14:13 ipfire Keepalived[24948]: Starting VRRP child process, pid=24949
Mar 30 07:14:13 ipfire Keepalived[24948]: Startup complete
Mar 30 07:14:13 ipfire Keepalived_vrrp[24949]: (VI_1) Entering BACKUP STATE (init)
Mar 30 07:14:13 ipfire kernel: DROP_OUTPUT IN= OUT=blue0 SRC=192.168.10.3 DST=224.0.0.22 LEN=40 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 MARK=0xd4
Mar 30 07:14:13 ipfire lldpd[24976]: /etc/localtime copied to chroot
Mar 30 07:14:13 ipfire lldpd[24976]: protocol LLDP enabled
Mar 30 07:14:13 ipfire lldpd[24976]: protocol CDPv1 enabled
Mar 30 07:14:13 ipfire lldpd[24976]: protocol CDPv2 enabled
Mar 30 07:14:13 ipfire lldpd[24976]: protocol SONMP disabled
Mar 30 07:14:13 ipfire lldpd[24976]: protocol EDP disabled
Mar 30 07:14:13 ipfire lldpd[24976]: protocol FDP disabled
Mar 30 07:14:13 ipfire lldpd[24976]: libevent 2.1.12-stable initialized with epoll method
Mar 30 07:14:13 ipfire kernel: tun: Universal TUN/TAP device driver, 1.6
Mar 30 07:14:13 ipfire openvpnserver[24992]: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Mar 30 07:14:13 ipfire openvpnserver[24992]: OpenVPN 2.6.17 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mar 30 07:14:13 ipfire openvpnserver[24992]: library versions: OpenSSL 3.6.1 27 Jan 2026, LZO 2.10
Mar 30 07:14:13 ipfire openvpnserver[24993]: MANAGEMENT: unix domain socket listening on /var/run/openvpn.sock
Mar 30 07:14:13 ipfire openvpnserver[24993]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Mar 30 07:14:13 ipfire openvpnserver[24993]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 30 07:14:13 ipfire openvpnserver[24993]: Diffie-Hellman initialized with 4096 bit key
Mar 30 07:14:13 ipfire openvpnserver[24993]: CRL: loaded 1 CRLs from file /var/ipfire/ovpn/crls/cacrl.pem
Mar 30 07:14:13 ipfire openvpnserver[24993]: TUN/TAP device tun0 opened
Mar 30 07:14:13 ipfire openvpnserver[24993]: /sbin/ip link set dev tun0 up mtu 1420
Mar 30 07:14:13 ipfire openvpnserver[24993]: /sbin/ip link set dev tun0 up
Mar 30 07:14:13 ipfire openvpnserver[24993]: /sbin/ip addr add dev tun0 ............/24 broadcast +
Mar 30 07:14:13 ipfire openvpnserver[24993]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Mar 30 07:14:13 ipfire openvpnserver[24993]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Mar 30 07:14:13 ipfire openvpnserver[24993]: UDPv4 link local (bound): [AF_INET][undef]:1194
Mar 30 07:14:13 ipfire openvpnserver[24993]: UDPv4 link remote: [AF_UNSPEC]
Mar 30 07:14:13 ipfire openvpnserver[24993]: GID set to nobody
Mar 30 07:14:13 ipfire openvpnserver[24993]: UID set to nobody
Mar 30 07:14:13 ipfire openvpnserver[24993]: MULTI: multi_init called, r=256 v=256
Mar 30 07:14:13 ipfire openvpnserver[24993]: IFCONFIG POOL IPv4: base.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: ifconfig_pool_read(), in.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: succeeded -> ifconfig_po.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: ifconfig_pool_read(), in.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: succeeded -> ifconfig_po.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: ifconfig_pool_read(), in.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: succeeded -> ifconfig_po.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: ifconfig_pool_read(), in.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: succeeded -> ifconfig_po.........................................
Mar 30 07:14:13 ipfire openvpnserver[24993]: IFCONFIG POOL LIST
Mar 30 07:14:13 ipfire openvpnserver[24993]: ipfire.........................5.2,
Mar 30 07:14:13 ipfire openvpnserver[24993]: redmi................5.3,
Mar 30 07:14:13 ipfire openvpnserver[24993]: tab16................4,
Mar 30 07:14:13 ipfire openvpnserver[24993]: mateboo.....................5,
Mar 30 07:14:13 ipfire openvpnserver[24993]: Initialization Sequence Completed
Mar 30 07:14:13 ipfire lldpcli[24975]: description set to new value ipfire
Mar 30 07:14:13 ipfire lldpcli[24975]: lldpd should resume operations
Mar 30 07:14:13 ipfire root: Could not find a master zone for tun0
Mar 30 07:14:13 ipfire openvpnserver[24993]: MANAGEMENT: Client connected from /var/run/openvpn.sock
Mar 30 07:14:14 ipfire dhcp[24868]: Unbound is running as PID 16060
Mar 30 07:14:14 ipfire dhcp[24868]: Acquired PIDFD 6 for PID 16060
Mar 30 07:14:14 ipfire dhcp[24868]: Reading static hosts from /var/ipfire/main/hosts
Mar 30 07:14:14 ipfire dhcp[24868]: Static hosts:
