Zentyal version 8.0.3. We have been using Zentyal for many years.
We have recently started having issues with our DHCP causing loss of client device connectivity. Clients devices seem to be losing IP addresses for a period of time before re-establishing new ones.
We are a moderately small office and have just one range of DHCP IP's available (currently 10.0.0.59 - 10.0.0.254), the rest being reserved for servers, some Dev PC's and other network devices such as printers, switches etc.
Looking at the content of our leases file (/var/lib/dhcp/dhcpd.leases), we see a mix of some very old expired leases (from November 2023), current leases (3rd June 2024) and some leases (current) with some sort of scripting for "on expiry" and "on release".
I don't know if the two script blocks are legitimate entries, since not all entries have this format.
Our leases file is also getting very long, with over eight TEN thousand lines (increased during time of writing this post) of lease entries (lines bulked by the coded outputs as exampled below), almost all of them dated for today.
Example of the scripting:
on expiry {
set ClientIP =
binary-to-ascii (10, 8, ".", leased-address) ;
log (debug,
concat ("Expired: IP: ", ClientIP));
execute ("/usr/share/zentyal-dhcp/dhcp-dyndns.sh", "delete", ClientIP, "", "0");
}
on release {
set ClientIP =
binary-to-ascii (10, 8, ".", leased-address) ;
set ClientDHCID =
concat (concat (concat (concat (concat (concat (concat (concat (concat (
concat
(
suffix
(
concat
(
"0",
binary-to-ascii
(16
,
8,
""
,
substring
(
hardware,
1,
1)
))
,
2)
,
":")
,
suffix
(
concat
(
"0",
binary-to-ascii
(16
,
8,
""
,
substring
(
hardware,
2,
1)
))
,
2)
), ":"),
suffix (concat (
"0",
binary-to-ascii
(16
,
8,
""
,
substring
(
hardware,
3,
1)
))
, 2)),
":"),
suffix (concat ("0",
binary-to-ascii
(16, 8, "",
substring (
hardware,
4, 1))), 2)),
":"),
suffix (concat ("0",
binary-to-ascii (16, 8, "",
substring (
hardware,
5, 1))), 2)),
":"),
suffix (concat ("0",
binary-to-ascii (16, 8, "",
substring (hardware, 6, 1))), 2
)) ;
log (debug,
concat ("Release: IP: ", ClientIP));
execute ("/usr/share/zentyal-dhcp/dhcp-dyndns.sh", "delete", ClientIP, ClientDHCID);
}
Can anyone enlighten me as to whether we have a buggy DHCP service (if so, what should I do to remedy), and whether I should try deleting the old or oddly-formed lease entries from the file in an effort to resolve it?
(I have made a backup copy of the file already.)
Thanks in advance,
Alec
=============== UPDATE (4th June 24) ================
Applying some basic troubleshooting/elimination processes on our network devices, I turned off our new WiFi AP (an Ubiquiti U7 Pro) and the address loss/reclaiming seems to have stabilised. Perhaps a bit early to tell after only a couple of hours, as we had seen things stabilise after the morning anyway - so tomorrow morning should provide the real test of whether that device had been doing something rogue on the LAN. It had applied an update back on 9th May (to v. 7.0.47), and we think that date is around when we started seeing the connectivity issues, but not sure why it had become increasingly worse during the last couple of weeks.
Have ordered a pair of NetGear AP's to test/replace the Ubiqiti stuff...
==============================================
Topic: DHCP Leases file garbage? (Read 1616 times)