|Summary:||dhclient Rebind msg send time error|
|Product:||[Fedora] Fedora||Reporter:||Yang Ren <ryang>|
|Component:||dhcp||Assignee:||Jiri Popelka <jpopelka>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||jpopelka, llim, ovasik|
|Fixed In Version:||dhcp-4.1.1-13.fc12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||559404 (view as bug list)||Environment:|
|Last Closed:||2010-04-22 22:34:39 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Comment 1 Jiri Popelka 2010-02-19 16:26:15 UTC
Hi (In reply to comment #0) > In the test. > Server T1 = 50 T2 = 80 > Client T1 = 3600 T2 = 5400 > > In rfc3315 18.1.4 > It said > "At time T2 for an IA(which will only be reached if the server to which the > renew mes was sent at time T1 has not responded)... the client initiates a > rebind/reply msg exchange with any available server" > I think that means server if server did not respond renew msg which was sent at > time T1(50) then at T2(80) or early then T2(80) a rebind msg should be sent. > That means after renew msg sent there is T2-T1 = 30s left to send a rebind msg. My english is not perfect but I think the "At time T2" means after the T2 is reached. > I'm not sure my opinion is right. Filed this bug for discuss. > See also last paragraph of 18.1.3: "The (Renew) message exchange is terminated when time T2 is reached, at which time the client begins a Rebind message exchange." This also says (I think) that Rebind msg exchange begins when T2 is reached. I'm sorry, but I don't see in RFC3315 any note saying that rebind msg should be sent before T2 is reached. > Actual results: > client will send rebind msg about 50s later Now I try to show you how it actually works: Client sends Renew in T1. If he gets no answer, he retransmits it in REN_TIMEOUT (see RFC 3315, section 5.5) seconds. If there's still no answer he doubles the interval (so now it is 2*REN_TIMEOUT) and retransmits it after this new interval. An so on (every time he doubles the interval). Everytime before sending the renew he checks whether T2 was reached. If he finds that T2 was reached, he goes to rebind state and starts sending rebind instead of renew. This retransmission strategy is described in RFC 3315, section 14. > Expected results: > Should send rebind msg within T2-T1(30s) As mentioned above, I think RFC3315 says that rebind msg should be send when (means after, not before) T2 is reached. > Additional info: I also searched what documentation says about T1 and T2 times in DHCP for IPv4. In RFC 2131 in section 4.4.5 (http://www.freesoft.org/CIE/RFC/2131/34.htm) I found: "T2 is the time at which the client enters the REBINDING state and attempts to contact any server." That I think says the same (for dhcp for ipv4): that client starts rebindind after (not before) T2 is reached.
Comment 2 Yang Ren 2010-02-25 06:20:06 UTC
Happy new year I just back from Spring festival. :) For this problem, My purpose is find the test fail reason and help our software be perfect. I agree with your opinion, I'll look the test result detail and turn to tahi mail list if necessary. Will update it here later.
Comment 5 Jiri Popelka 2010-03-11 11:39:00 UTC
I was searching in the DHCP Handbook what it says to T2 time and found these: "T2 is the time when a client begins finding a new server through which it can extend the lease on its address. Beginning at time T2, the client broadcasts DHCPREQUEST messages to locate a server that is willing to extend its lease. " "T2: The time at which a DHCP client begins to attempt to extend the lease on its assigned IP address from any available DHCP server." "DHCPv6 defines T1 and T2 in the same way as DHCPv4"  http://www.dhcp-handbook.com Authors (Ralph Droms, Ted Lemon) of this book are authors of DHCP RFCs.
Comment 6 Yang Ren 2010-03-11 11:59:15 UTC
En, I understand, So i suggest that u can close the bug for now with not a bug. I'll submit another one once I find the true reason that make the test failed. There are something more urgent in hand. May got time to work on finding the result from next week.
Comment 7 Yang Ren 2010-03-16 07:43:02 UTC
I confirmed that test suite assume the time gap between reply msg and rebind msg should be T2. between reply msg and renew msg should be T1. And 5% decination is acceptable. And I also go back rfc3315 In Section 14. Reliability of Client Initiated Message Exchanges. MRD Maximum retransmission duration And In Section 18.1.3 MRD Remaining time until T2 I think it may means (T2 - T1)? I'm curious what's the behavior now. T1=50 T2=80 If T2 is the time after got renew message. The time should be 130 right? But now The rebind msg will be send about 100 after got reply msg. This is part of result time1:76 (time1 = T2*0.95) time2:84 (time2 = T2*1.05) frame:dhcp6_rebind Count:3 recvTimeCnt:1268752198.172816 senttime1:1268752098.913924 NG: The Received time error! The pass situation is time1 < (recvTimeCnt - senttime1) < time2 U can find test result here. http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/index.html
Comment 8 Yang Ren 2010-03-16 07:46:19 UTC
Created attachment 400396 [details] Test output This is the test result of rebind send time error. recvtime is a little out of range.
Comment 9 Yang Ren 2010-03-16 07:49:13 UTC
> U can find test result here. > http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/index.html This is the url http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/5.html
Comment 10 Fedora Update System 2010-03-25 19:00:31 UTC
dhcp-4.1.1-15.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/dhcp-4.1.1-15.fc13
Comment 11 Fedora Update System 2010-03-25 19:03:56 UTC
dhcp-4.1.1-13.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/dhcp-4.1.1-13.fc12
Comment 12 Yang Ren 2010-03-26 09:34:22 UTC
Verified in dhcp-4.1.1-13.fc12 Great job. Thanks.
Comment 13 Fedora Update System 2010-03-27 01:01:40 UTC
dhcp-4.1.1-13.fc12 has been pushed to the Fedora 12 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: http://admin.fedoraproject.org/updates/dhcp-4.1.1-13.fc12
Comment 14 Fedora Update System 2010-04-21 21:51:46 UTC
dhcp-4.1.1-15.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2010-04-22 22:34:10 UTC
dhcp-4.1.1-13.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.