I’ve got new log entries in the log suddenly appearing from Oct 30. I swear that was before I began working on HAProxy 
Unknown Entries:
execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client: 384 Time(s)
execute_statement argv[1] = commit: 384 Time(s)
execute_statement argv[2] = ADDRESS=XXX.XXX.XXX.XXX: 49 Time(s)
execute_statement argv[2] = ADDRESS=YYY.YYY.YYY.YYY: 49 Time(s)
.
.
.
execute_statement argv[2] = ADDRESS=ZZZ.ZZZ.ZZZ.ZZZ: 9 Time(s)These entries are generated by the new part of the unbound-dhcp-leases-bridge, the unbound-dhcp-leases-client.
The …-bridge registers (name, IP) tupels to unbound, the DNS server. The …-client is called from the DHCP server, when new leases are generated, and sends the information to the …-bridge.
This functionality is new to IPFire and I suppose these log entries will disappear in case of proof of functioning with one of the next CUs.
Thanks for clarifying, I was guessing in this direction. But I think it’s a bit strange why this began to appear not directly after the core upgrade but two weeks later.
To this matter I have a further question. Additionally to the entries similar to the above mentioned, there I also find entries that are headlined with “unknown entries”. What does this mean and is it a sign of misconfig?
Thx 4 your feedback!`
Unknown Entries:
execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client: 481 Time(s)
execute_statement argv[1] = commit: 481 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.101: 10 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.102: 48 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.116: 24 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.117: 48 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.120: 10 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.150: 5 Time(s)
execute_statement argv[2] = ADDRESS=192.168.2.160: 4 Time(s)
execute_statement argv[2] = ADDRESS=192.168.3.101: 38 Time(s)
execute_statement argv[2] = ADDRESS=192.168.3.105: 50 Time(s)`
...
execute_statement argv[3] = NAME=: 61 Time(s)
execute_statement argv[3] = NAME=C225: 52 Time(s)
execute_statement argv[3] = NAME=DAB-WW: 49 Time(s)
...There are two bugs raised related to messages in the dhcp logs.
https://bugzilla.ipfire.org/show_bug.cgi?id=13801
https://bugzilla.ipfire.org/show_bug.cgi?id=13802
I don’t see these in my dhcp logs at all so it is also dependent on the setup. Mine is 100% fixed lease, except when I have visitors staying over when I use dynamic leases on the blue network.
Maybe you could give some info into the appropriate bug as to what mix of fixed lease and dynamic lease operation you are using in your setup.
@firewire and @waynetsun,
I am curious what core update you are using.
TL;DR . . .
I use dynamic, fixed and static (about 30 network devices total).
I looked through all of my message logs and I do not see log entries with Unknown Entries: or ending with : nnn Time(s)
Log entries like this are normal:
Dec 21 11:21:26 ipfire dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
Dec 21 11:21:26 ipfire dhcpd: execute_statement argv[1] = commit
Dec 21 11:21:26 ipfire dhcpd: execute_statement argv[2] = ADDRESS=192.168.60.240
Dec 21 11:21:26 ipfire dhcpd: execute_statement argv[3] = NAME=deb12HPZ
It comes from dhcpd when the /etc/dhcp/dhcpd.conf includes an execute statement. In this case it executes /usr/sbin/unbound-dhcp-leases-client
EDIT: It looks like the unbound-dhcp-leases-client was rolled out with CU 188
and it was updated a bit in CU190.
Interesting that @jon doesn’t see those entries.
I also hadn’t seen them and i only use fixed leases so i thought it was when dynamic leases are used that the messages are seen. @jon input means that there must be some other thing triggering the messages to occur.
@jon could you put your input into the bugs as well. Thanks.
As @jon said, the messages are from the new mechanism for sending DHCP lease to unbound.
The amount is dependent on lease time and number of clients requesting an IP.
See also my ‘solution’ from November.
They show up as unknown entries, because the WUI doesn’t know ( yet ) from these new messages.
OK, so you are saying this is the log info from the normal working of the modified unbound-dhcp-leases-bridge and after it is clear that everything is working okay these messages should be fed to null and no longer recorded in the logs.
I just realised these entries are not in the dhcp server system log section. They are being seen in the Log Summary WUI page.
In that case, I also am seeing some of them.
Thx for your time!
FYI…I am using core update 190, but saw these entries on 189 as well.
All devices have fixed leases.
In the argv(3) name section there are wrong names of devices.
I.e.
execute_statement argv[3] = NAME=: 64 Time(s)
execute_statement argv[3] = NAME=360_CleanRobot_T9: 48 Time(s)
The name of this device is set in device settings and at ipfire /network/hosts as „robot“.
Some devices, even if they have the ability to have a hostname set will still use their own defined hostname when requesting a dhcp address.
My TV has happily accepted the hostname I set in its settings but my Blu-Ray player insists on using its own fixed completely different hostname when requesting a dhcp address even though in its settings I have defined my own hostname.
Poor coding from the device manufacturer. You just have to live with it.
Good thing is that in the IPFire network and with things like WIO it is the hostname that we have defined in the Hosts WUI list that is used and not the hostname that the device used in its dhcp communication.
it would be nice if it cleaned its invalid DHCP entries. I see expired ones from previous versions. Which one would think they would clean up logs and expired leases before upgrading the os. But I guess that was wishful thinking.
