One of my interfaces is really slow (it may be DHCP, not the firewall)
-
Re: One of my interfaces is really slow
I am looking at my DHCP log and see lots of entries like this:
Feb 22 21:31:59 dhcpd 92991 DHCPDISCOVER from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:31:59 dhcpd 92991 DHCPOFFER on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:00 dhcpd 92991 DHCPREQUEST for 192.168.2.24 (192.168.2.1) from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:00 dhcpd 92991 DHCPACK on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:03 dhcpd 92991 DHCPDECLINE of 192.168.2.24 from 94:ea:32:6e:7f:8b via mvneta0.4092: not found Feb 22 21:32:13 dhcpd 92991 DHCPDISCOVER from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:13 dhcpd 92991 DHCPOFFER on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:14 dhcpd 92991 DHCPREQUEST for 192.168.2.24 (192.168.2.1) from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:14 dhcpd 92991 DHCPACK on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:16 dhcpd 92991 DHCPDECLINE of 192.168.2.24 from 94:ea:32:6e:7f:8b via mvneta0.4092: not found Feb 22 21:32:26 dhcpd 92991 DHCPDISCOVER from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:26 dhcpd 92991 DHCPOFFER on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:27 dhcpd 92991 DHCPREQUEST for 192.168.2.24 (192.168.2.1) from 94:ea:32:6e:7f:8b via mvneta0.4092 Feb 22 21:32:27 dhcpd 92991 DHCPACK on 192.168.2.24 to 94:ea:32:6e:7f:8b via mvneta0.4092
Other hosts trying to get on the WiFi network are doing the same thing. I think this excessive DHCP communication is bogging down the whole subnet.
However, I am not at all sure, what the reason for this might be.
What does the “not found” in
Feb 22 21:32:16 dhcpd 92991 DHCPDECLINE of 192.168.2.24 from 94:ea:32:6e:7f:8b via mvneta0.4092: not found
mean?
One of my static lease entries for this interface had this set:
Could this have been the problem?
I made some changes to the DHCP configuration. Now I see a lot of entries like this one:
Feb 22 22:18:52 dhcpd 65513 DHCPDISCOVER from 94:b9:7e:51:fb:c4 via mvneta0.4092: network 192.168.2.0/24: no free leases
I have 20–30 devices looking for IPs. My range currently is about 70 addresses long. The first 12 of those have been assigned. There is no way that the DHCP has run out of leases.
One more clue: I recently switched the interface from 192.168.4.0/24 to 192.168.2.0/24 but kept the SSIDs of the access points providing WiFi connectivity the same. All the devices having issues are connecting through those access points.
-
-
I think, the solution has been to make enough changes to my list of static leases and the range of DHCP IP addresses. My understanding is that, as hosts grab new IP addresses, this clears out some of the leases from the DHCP server’s list. That, in turn, reduces the churn on the network with devices trying to get an IP address, but failing.
-
… and what is happening here?
Feb 22 23:21:48 dhcpd 62415 DHCPACK on 192.168.2.15 to 58:d5:0a:ae:0f:7e via mvneta0.4092 Feb 22 23:23:01 dhcpd 62415 DHCPREQUEST for 192.168.2.43 from 3c:22:fb:79:9a:67 (BenedictMBA) via mvneta0.4092 Feb 22 23:23:01 dhcpd 62415 DHCPACK on 192.168.2.43 to 3c:22:fb:79:9a:67 (BenedictMBA) via mvneta0.4092 Feb 22 23:23:05 dhcpd 55634 Internet Systems Consortium DHCP Server 4.4.3-P1 Feb 22 23:23:05 dhcpd 55634 Copyright 2004-2022 Internet Systems Consortium. Feb 22 23:23:05 dhcpd 55634 All rights reserved. Feb 22 23:23:05 dhcpd 55634 For info, please visit https://www.isc.org/software/dhcp/ Feb 22 23:23:05 dhcpd 55634 Config file: /etc/dhcpd.conf Feb 22 23:23:05 dhcpd 55634 Database file: /var/db/dhcpd.leases Feb 22 23:23:05 dhcpd 55634 Internet Systems Consortium DHCP Server 4.4.3-P1
Does the process ID roll over from 62415 to 55634 as a matter of course, or is it an indication that Process 62415 crashed and is respawned with a different ID?
-
I ended up deleting the interface and building it from scratch. It was mainly the effort of redoing the static DHCP leases. I had set up a dummy interface first and copied the rules over to that one, and then back to the redone interface.
That fixed everything. It must have been some kind of corruption I could not shake in any other way.