Bug 585418 - dhclient honors already-expired leases
dhclient honors already-expired leases
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-23 19:09 EDT by Dan Williams
Modified: 2010-11-01 16:48 EDT (History)
1 user (show)

See Also:
Fixed In Version: dhcp-4.2.0-12.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-01 16:48:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log of dhcpv6 transaction with long-expired lease (4.84 KB, text/plain)
2010-04-23 19:10 EDT, Dan Williams
no flags Details
Lease file passed to dhclient (1.03 KB, text/plain)
2010-04-23 19:14 EDT, Dan Williams
no flags Details

  None (edit)
Description Dan Williams 2010-04-23 19:09:26 EDT
Ran into this problem testing NM with DHCPv6:

Max retransmission duration exceeded.
PRC: Bound to lease 00:01:00:01:12:e1:92:d9:00:14:22:fd:06:e7.
PRC: Rebind event scheduled in -8604281 seconds, to run for 110 seconds.
PRC: Depreference scheduled in -8604241 seconds.
PRC: Expiration scheduled in -8604171 seconds.
PRC: Rebinding lease on eth0.
PRC: Depreference scheduled in -8604241 seconds.
PRC: Expiration scheduled in -8604171 seconds.
NetworkManager: <info> (eth0): DHCPv6 state changed preinit6 -> bound6
Comment 1 Dan Williams 2010-04-23 19:10:31 EDT
Created attachment 408757 [details]
Log of dhcpv6 transaction with long-expired lease
Comment 2 Dan Williams 2010-04-23 19:14:24 EDT
Created attachment 408759 [details]
Lease file passed to dhclient
Comment 3 Jiri Popelka 2010-04-24 08:24:42 EDT
There's no NVR mentioned, but I guess this appeared with upgrade to dhcp-4.1.1-13.fc12, right ?

Can you confirm that this problem doesn't occur with previous build, i.e. dhcp-4.1.1-12.fc12 ?
http://koji.fedoraproject.org/koji/buildinfo?buildID=163453

Thank you
Comment 4 Jiri Popelka 2010-04-26 04:05:58 EDT
(In reply to comment #3)

s/dhcp-4.1.1/dhclient-4.1.1/
Comment 5 Jiri Popelka 2010-04-26 08:11:58 EDT
It looks that this has nothing to do with what I changed (I added some missing features so dhclient can pass TAHI tests and obtain IP6Ready Logo) in few last builds. So please ignore comment #3.

Now to the log. 
I'm not (yet) experienced in how the NM uses dhclient, but I see in the log this:

1)
> XMT: Confirm on eth0, interval 2470ms.
> Max retransmission duration exceeded.
> PRC: Bound to lease 00:01:00:01:12:e1:92:d9:00:14:22:fd:06:e7.
> PRC: Rebind event scheduled in -8604281 seconds, to run for 110 seconds.
> PRC: Depreference scheduled in -8604241 seconds.
> PRC: Expiration scheduled in -8604171 seconds.
> PRC: Rebinding lease on eth0.
> PRC: Depreference scheduled in -8604241 seconds.
> PRC: Expiration scheduled in -8604171 seconds.
Client was unsuccessful in its trying to Confirm the old address from server.
Then client continues to use old IP address, using the last known lifetimes for this address,
because Section 18.1.2. (Creation and Transmission of Confirm Messages)
of RFC 3315 says:
"   If the client receives no responses before the message transmission
   process terminates, as described in section 14, the client SHOULD
   continue to use any IP addresses, using the last known lifetimes for
   those addresses, and SHOULD continue to use any other previously
   obtained configuration parameters."
2)
> PRC: Address 3ffe:501:ffff::4 depreferred.
> PRC: Expiration scheduled in -8604171 seconds.
> PRC: Address 3ffe:501:ffff::4 expired.
> PRC: Bound lease is devoid of active addresses.  Re-initializing.
> PRC: Soliciting for leases (INIT).
> XMT: Forming Solicit, 0 ms elapsed.
> XMT:  X-- IA_NA 5a:47:1f:71
> XMT:  | X-- Request renew in  +3600
> XMT:  | X-- Request rebind in +5400
> XMT: Solicit on eth0, interval 1040ms.
Imediatelly after the dhclient starts to use the address it discovers that the valid lifetime of the address has expired. According to RFC 3315 it goes to INIT state and sends Solicit message to locate new DHCP server.

So you are right that dhclient honors already-expired leases, but for me it looks like that's what RFC says. I'll continue to investigate this.
Comment 6 Jiri Popelka 2010-08-11 13:01:31 EDT
Dan,

I'm just looking at
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f630d433e20746226a53c08afedafa9596816a
"
... Otherwise dhclient complains about not being able to send outgoing traffic from it's send_packet6() function with "no route to host". It will then use an expired lease, which causes NM to assign that leases IP address to the interface, which causes the kernel to assign the required ff00::/8 route, and then dhclient performs a renew (since the expired lease has expired of course) and then everything works out in the end. But the latency sucks. 
"

Seems like I can close this as notabug (see also my previous comment), right ?
Comment 7 Dan Williams 2010-08-11 13:12:37 EDT
I'm not sure; this will happen *any* time the DHCPv6 server can't be contacted, and then dhclient will send NM a long-expired address to use, then immediately expire the lease and try again.

I still believe that dhclient simply shouldn't be binding to long-expired leases.  If the lease was valid 10 mintues ago then sure; but I've seen the client bind to leases that expired 6 hours ago, then immediately expire it and try again.  If the lease is expired, why not just start trying again instead of binding to it in the first place?
Comment 8 Dan Williams 2010-08-11 13:15:17 EDT
I mean, there's really no excuse for something like this:

> PRC: Bound to lease 00:01:00:01:12:e1:92:d9:00:14:22:fd:06:e7.
> PRC: Rebind event scheduled in -8604281 seconds, to run for 110 seconds.
> PRC: Depreference scheduled in -8604241 seconds.

that lease is so long expired that it shouldn't even have been bound in the first place... 

The section from RFC 3315 is valid, yes, but if the lease has already expired, why is the client trying to confirm it at all?  I'd expect that if the lease is still valid and the client doesn't get a confirm that it could keep using that lease until it expires.  But not if the lease expired 5 days ago.
Comment 9 Jiri Popelka 2010-10-07 09:15:53 EDT
Fixed in dhcp-4.2.0-10.fc14

http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=commitdiff;h=2b3afb07c975686fcfb81546768deb61335987eb

I don't think this change will be accepted upstream
because ISC dhcp is described as a 'Reference Implementation',
i.e. it's written to behave precisely as appears in
reference material (IETF RFC's).
But we can try :-)
Comment 10 Fedora Update System 2010-10-13 07:11:05 EDT
dhcp-4.2.0-12.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/dhcp-4.2.0-12.fc14
Comment 11 Fedora Update System 2010-10-13 17:21:42 EDT
dhcp-4.2.0-12.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dhcp-4.2.0-12.fc14
Comment 12 Fedora Update System 2010-11-01 16:48:01 EDT
dhcp-4.2.0-12.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.