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
Created attachment 408757 [details] Log of dhcpv6 transaction with long-expired lease
Created attachment 408759 [details] Lease file passed to dhclient
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
(In reply to comment #3) s/dhcp-4.1.1/dhclient-4.1.1/
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.
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 ?
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?
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.
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 :-)
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
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
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.