Bug 126551
Summary: | dhclient generates wrong lease records | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | goahead <goahead> | ||||
Component: | dhcp | Assignee: | Jason Vas Dias <jvdias> | ||||
Status: | CLOSED ERRATA | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 2 | CC: | goahead | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-07-29 19:54:19 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
goahead
2004-06-23 03:37:08 UTC
I looked into old lease files. In all lease records the "expire" field has an offset of -7200. When expire should be 5:58:03 it is 3:58:03. The "rebind" field is always 675s less than "expire". The offset for "renew" is different in all records. I updated dhclient to dhclient-3.0.1rc14-1 in the meantime. The problem remains. The DHCP lease times are written in GMT - so you must be at GMT +2:00 ? So you get a lease at 4:28, (02:28 GMT) and it will expire 5400 seconds later at 03:58 GMT, hence the entries in your dhclient.leases file. See manual page for dclient.leases(5) about configuring rebind & renew offsets. In the light of the above, does this statement still hold : " The usual lease time of my ISP is 5400. Still, dhclient renews the lease after about 1/3 of the lease time. So during each 5400s period the lease is renewed twice. " If so, please open a new bug about "dhcp leases expire before lease time" . I noticed that the 7200 sec difference equals the delta between UTC and my local time which is CEST. In RFC 2131 the timers T1 and T2 are defined. At T1 "the client moves to RENEWING state". "T1 defaults to (0.5 * duration_of_lease)" +- some fuzz around the value. As the amount of fuzz is not defined it could be anything. So there seems to be nothing wrong about the leases being renewed after 1/3 of the lease time. So this is not a bug, just disturbing. I'll switch back to pump. Created attachment 102331 [details]
During each 5400 sec period 2 leases are acquired
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-566.html |