One of my interfaces is really slow (it may be DHCP, not the firewall)

[DominikHoffmann]

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.

[DominikHoffmann]

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.

[DominikHoffmann]

… 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?

[DominikHoffmann]

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.