Hi Guys, since my upgrade from 8.1 to 8.2 I have this appearing every 5 mins in /var/log/messages: Apr 23 17:34:56 buddha dhcpcd[835]: dhcpIPaddrLeaseTime=600 in DHCP server response. Apr 23 17:34:56 buddha dhcpcd[835]: dhcpT1value is missing in DHCP server response. Assuming 300 sec Apr 23 17:34:56 buddha dhcpcd[835]: dhcpT2value is missing in DHCP server response. Assuming 525 sec So apparently dhcpcd is renewing its lease every 3 mins according to "T1 value", which is not documented anywhere. I have googled on this and found a fix, with the remark that it is built into the version 8.2 carries. What gives ? Anybody seen this, dealt with this ? Regards Dan
On Wednesday 23 April 2003 17:43, Dan Am wrote:
Hi Guys,
since my upgrade from 8.1 to 8.2 I have this appearing every 5 mins in /var/log/messages:
Apr 23 17:34:56 buddha dhcpcd[835]: dhcpIPaddrLeaseTime=600 in DHCP server response. Apr 23 17:34:56 buddha dhcpcd[835]: dhcpT1value is missing in DHCP server response. Assuming 300 sec Apr 23 17:34:56 buddha dhcpcd[835]: dhcpT2value is missing in DHCP server response. Assuming 525 sec
So apparently dhcpcd is renewing its lease every 3 mins according to "T1 value", which is not documented anywhere.
300 seconds isn't 3 minutes, as far as I know we're still counting minutes the Babylonian way. But why on earth is your dhcp server setting a lease time of 10 minutes. dhcpcd isn't really doing anything wrong here, trying to renew the lease after half the lease time is up is standard practice. Get the admin to up the lease time instead.
Anders, ... I was a bit quick on the reply there. Now I get this: Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpIPaddrLeaseTime=86400 in DHCP server response. Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpT1value is missing in DHCP server response. Assuming 43200 sec Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpT2value is missing in DHCP server response. Assuming 75600 sec Am Mittwoch, 23. April 2003 17:53 schrieb Anders Johansson:
trying to renew the lease after half the lease time is up is standard practice. If I read that carefully, it can't be right. I set the value so that it renews after half of the value ? I still think there is something not quite right here. Anyhow, my immedeate problem is solved, so thanks a lot.
Regards Dan
On Wednesday 23 April 2003 18:18, Dan Am wrote:
Anders, ... I was a bit quick on the reply there. Now I get this:
Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpIPaddrLeaseTime=86400 in DHCP server response. Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpT1value is missing in DHCP server response. Assuming 43200 sec Apr 23 18:05:10 192.168.0.26 dhcpcd[31405]: dhcpT2value is missing in DHCP server response. Assuming 75600 sec
Am Mittwoch, 23. April 2003 17:53 schrieb Anders Johansson:
trying to renew the lease after half the lease time is up is standard practice.
If I read that carefully, it can't be right. I set the value so that it renews after half of the value ?
No, so that it starts trying to renew after half the value. The lease time is, at least in theory, the maximum time a computer is allowed to use a certain IP address. After half that time, the dhcp client will start trying to renew the address for a further period. If the dhcp server is overloaded, that gives the client a nice buffer to try again. If it didn't try until the time was up, it would have to throw away the IP after the first failure. After the second time value is reached (T2), the client will abandon renewal tries and go for a completely new address.
Hi Anders, Am Mittwoch, 23. April 2003 18:24 schrieb Anders Johansson:
After the second time value is reached (T2), the client will abandon renewal tries and go for a completely new address. Looks like you know your stuff and I have some reading to do. I stand corrected. (Pulls his hat respectfully) :-) Dan
On Wednesday 23 April 2003 18:42, Dan Am wrote:
Hi Anders,
Am Mittwoch, 23. April 2003 18:24 schrieb Anders Johansson:
After the second time value is reached (T2), the client will abandon renewal tries and go for a completely new address.
Looks like you know your stuff and I have some reading to do. I stand corrected. (Pulls his hat respectfully)
:-)
OK, so that bit was wrong, it doesn't abandon renewal tries, it abandons the direct communication with the dhcp server and broadcasts the request instead. I wrote it quickly and phrased it badly. Sorry
participants (2)
-
Anders Johansson
-
Dan Am