My DHCP log has lot of entries (over 6000 daily) and multiple times. it is normal?
…
|00:02:24|dhcpd:|DHCPREQUEST for 192.168.102.13 from 00:04:13… via green0|
|00:02:24|dhcpd:|DHCPACK on 192.168.102.13 to 00:04:13… via green0|
…
|00:32:24|dhcpd:|DHCPREQUEST for 192.168.102.13 from 00:04:13… via green0|
|00:32:24|dhcpd:|DHCPACK on 192.168.102.13 to 00:04:13… via green0|
…
|01:02:24|dhcpd:|DHCPREQUEST for 192.168.102.13 from 00:04:13… via green0|
|01:02:24|dhcpd:|DHCPACK on 192.168.102.13 to 00:04:13… via green0|
…
If your DHCP Configuration has small default lease time and max lease time, you will see many entries. I think the default is 30 / 60 but you can increase it so that you get fewer requests in the log.
1 Like
Thank you Paul, my settings: 60/120
Sorry for borrowing/stealing this thread…
To me 30 min / 60 minutes seems like setting for a coffee shop, etc. with turnover of people & devices happening somewhat fast.
Is there a recommended setting for Home users of maybe Small Office users where people & devices hardly ever turnover?
I’m currently set to 300 min / 600 minutes for no real reason except it was easy to add a zero to each default number! 
What do others use and why?
1 Like
The times you need to set are very dependent on the use case. Mine is a home network with a few servers, switches, printers and WAP’s and not a high guest demand.
For me everything on Green uses fixed IP allocation via DHCP. This covers both wired and wireless. So on Green I have set 8 days. Leases will attempt to be renewed at 50% of this default time if they are being actively used.
My Blue is for my guest wifi, so there I am using dynamic allocation and have the default time set to 24 hours as they tend to only use it for a few days at a time.
If you were running a hotspot at a cafe or for business guests you would probably use a much shorter time. Turnover of connections would be much higher and you would want to make sure you don’t run out of leases. So 10 hours might make sense for business guests down to maybe 10 to 30 mins for cafe hotspots.
It would also depend on how many IP’s you have available on your network and the user demand levels you have.
The Max values I set to twice the default, for no other reason than that the “default” value was twice the default lease.
1 Like
Having witten about the max lease time made me wonder what this parameter was there for so i had a read of the man page.
It turns out that the default lease time is the default if the client does not explicitly specify a lease time and the max lease time is the max that will be provided even if the client asks for longer. There is also a min lease time parameter applicable for dhcpd.conf
So the max value has no effect if your clients ask for a lease without specifying a lease time, which is the case for me.
It’s good to go back and revisit these things occassionally to learn what the things we specify are doing. 
1 Like
Thank you Adolf, that was very helpful, i change my setting to 14400/28800 and will watch what happens
Im not sure if my problem is related, but over the lasy couple of days I have noticed That reconnection’s to the network have been slow on my phone and several other devices, up to 2 hours including rebooting.
Looking at the DHCP log the number of entries has one from 5-600 a day to 3000 + and so far in the last 9 hours over 2000.
Many of the entries read similar to this :
| 00:01:34 | dhcpd: | DHCPREQUEST for 192.168.1.7 from 54:60:09:be:2c:66 (Chromecast) via green0 |
|---|---|---|
| 00:01:34 | dhcpd: | DHCPACK on 192.168.1.7 to 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:02:38 | dhcpd: | reuse_lease: lease age 16121 (secs) under 25% threshold, reply with unaltered, e xisting lease for 192.168.1.7 |
| 00:02:38 | dhcpd: | DHCPREQUEST for 192.168.1.7 from 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:02:38 | dhcpd: | DHCPACK on 192.168.1.7 to 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:03:42 | dhcpd: | reuse_lease: lease age 16185 (secs) under 25% threshold, reply with unaltered, e xisting lease for 192.168.1.7 |
| 00:03:42 | dhcpd: | DHCPREQUEST for 192.168.1.7 from 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:03:42 | dhcpd: | DHCPACK on 192.168.1.7 to 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:04:46 | dhcpd: | reuse_lease: lease age 16249 (secs) under 25% threshold, reply with unaltered, e xisting lease for 192.168.1.7 |
| 00:04:46 | dhcpd: | DHCPREQUEST for 192.168.1.7 from 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:04:46 | dhcpd: | DHCPACK on 192.168.1.7 to 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:05:50 | dhcpd: | reuse_lease: lease age 16313 (secs) under 25% threshold, reply with unaltered, e xisting lease for 192.168.1.7 |
| 00:05:50 | dhcpd: | DHCPREQUEST for 192.168.1.7 from 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:05:50 | dhcpd: | DHCPACK on 192.168.1.7 to 54:60:09:be:2c:66 (Chromecast) via green0 |
| 00:06:54 | dhcpd: | reuse_lease: lease age 16377 (secs) under 25% threshold, reply with unaltered, e xisting lease for 192.168.1.7 |
I recently upgraded to Core 154
Im not aware of any other changes to the network
This is a home network
Default lease time is 1400 max 2800
Any ideas of how to fix this would be appreciated
From your log, you have a Chromecast device that is asking for its dhcp lease every 1 minute and 4 seconds even though the server has a lease time of 1400 minutes. It should not be asking for a lease renewal until 700 minutes.
This seems to be a problem with the Chromecast device. Did it or the Chromecast app recently have an update?
1 Like
Thanks Adolf
I get the same messages for HP Printer, Thinkpad Yoga, Huwei Cellphone … usually every 60 seconds or so until it finally works. The Chromecast was just the one I chose as an example
It appears that I get the following message in the log when it successfully assigns a lease but not every time
07:45:10 dhcpd: Wrote 55 leases to leases file.
Here is another section of log with successful and unsuccessful requests
| 08:30:05 | dhcpd: | DHCPREQUEST for 192.168.1.118 from 94:10:3e:4e:2d:b1 (wemo) via green0 |
|---|---|---|
| 08:30:05 | dhcpd: | DHCPACK on 192.168.1.118 to 94:10:3e:4e:2d:b1 (wemo) via green0 |
| 08:41:22 | dhcpd: | reuse_lease: lease age 3079 (secs) under 25% threshold, reply with unaltered, ex isting lease for 192.168.1.15 |
| 08:41:22 | dhcpd: | DHCPREQUEST for 192.168.1.15 from 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via green0 |
| 08:41:22 | dhcpd: | DHCPACK on 192.168.1.15 to 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via gre en0 |
| 09:06:19 | dhcpd: | reuse_lease: lease age 4576 (secs) under 25% threshold, reply with unaltered, ex isting lease for 192.168.1.15 |
| 09:06:19 | dhcpd: | DHCPREQUEST for 192.168.1.15 from 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via green0 |
| 09:06:19 | dhcpd: | DHCPACK on 192.168.1.15 to 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via gre en0 |
| 09:09:25 | dhcpd: | DHCPREQUEST for 192.168.1.37 from e0:d5:5e:4b:5e:28 (Windows2018) via green0 |
| 09:09:25 | dhcpd: | Wrote 55 leases to leases file. |
| 09:09:25 | dhcpd: | DHCPACK on 192.168.1.37 to e0:d5:5e:4b:5e:28 (Windows2018) via green0 |
| 09:11:15 | dhcpd: | DHCPREQUEST for 192.168.1.28 from f4:09:d8:db:e9:a9 (android-9641556a1d22d54e) v ia green0 |
| 09:11:15 | dhcpd: | DHCPACK on 192.168.1.28 to f4:09:d8:db:e9:a9 (android-9641556a1d22d54e) via gree n0 |
| 09:16:01 | dhcpd: | reuse_lease: lease age 5158 (secs) under 25% threshold, reply with unaltered, ex isting lease for 192.168.1.15 |
| 09:16:01 | dhcpd: | DHCPREQUEST for 192.168.1.15 from 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via green0 |
| 09:16:01 | dhcpd: | DHCPACK on 192.168.1.15 to 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via gre en0 |
| 09:18:15 | dhcpd: | reuse_lease: lease age 5292 (secs) under 25% threshold, reply with unaltered, ex isting lease for 192.168.1.15 |
| 09:18:15 | dhcpd: | DHCPREQUEST for 192.168.1.15 from 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via green0 |
| 09:18:15 | dhcpd: | DHCPACK on 192.168.1.15 to 14:d1:69:90:98:82 (HUAWEI_Mate_20_Pro-5f9542) via gre en0 |
| 09:36:59 | dhcpd: | reuse_lease: lease age 6416 (secs) under 25% threshold, reply with unaltered, ex isting lease for 192.168.1.15 |
Tim
Do have the possibility to monitor the DHCP traffic one of these devices?
Are all DHCPACK received?
Are there retries for other traffic?
Maybe your wired connection isn’t full okay.
I just looked at my logs as well and I also see more frequent DHCPREQUEST entries when one of my clients is connected. In my case the frequency is not so high that I see the
message. However they are definitely more frequent than the 50% of default lease time.
The peculiar thing is that the request is coming from the client - DHCPREQUEST from hwaddress followed by the server sending the DHCPACK to say keep using this IP address so it seems to be triggered by the client but no idea why.
EDIT:-
Additional information from my logs is that the effect only seems to be with my clients that are connected via wireless. I just implemented a pair of new WAP’s so I will probably revert back to the previous ones and see if I still get the same messages. I will also check the older message logs in the morning and try and see how long this has been occurring.
EDIT2:-
Checked the old logs back to early Dec and the messages are there the whole time. They only show up when the laptop or mobile is actually connected to the wifi. So it is not related to the change of WAP or to the Core Update 154. The effect does not show up on the machines that are connected via wired connections.
Will try out the laptop with a wired connection tomorrow.
Thanks
Your posts got me thinking
My devices are all wireless so i rebooted the Wireless router and things seem to have dropped back to normal for the last 10 hours.
1 Like
Hi @stimk
So my laptop with wired connection had the first dhcp communication and then nothing further. So it is only happening with me with my wifi.
Your action of rebooting your wireless router has made me reboot both my WAP’s. I had set them up in multi-ssid mode but not rebooted after doing the setup.
Will wait and see if I also have things back to “normal”.
Please report back after a day or two on your status and I will do the same.
Just an idea about that.
DHCP uses UDP, packets are not repeated. So a lost ACK packet on the wireless isn’t received by the client.
If you only watch the server side ( IPFire ) you see the requests and responses, as it should be.
But you cannot see how many requests are not received by the server, as you can’t see the ACKs lost.
Because of this fact I asked for a trace of the client side.
1 Like
Hi Bernhard,
I will keep that in mind if the problem comes back. Since my reboot of my WAPs I no longer have the repeat messages every 5 to 10 secs. There is now the message when the connection is first made and the IP address is provided and then I have been running my laptop for over an hour and there is no further message, also not in the laptops logs.
So looks like rebooting the WAPs solved my problem. @stimk seems to have had the same result. As all of his clients are wireless, it will be good to see if the problem comes back or not.
All my permanently on systems are wired network. It is my mobile clients that use wireless so they don’t stay on all the time but definitely an improvement on what was in the logs before.
Hi Adolf.
Seems a good explanation. I don’t have the problem with AP reboot, because I use my wireless card with hostapd as AP. Each reboot and/or change in IPFire restarts the AP ( hostapd ) also.