Bug 559153

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.

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.

I was searching in the DHCP Handbook[1] 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"

[1] http://www.dhcp-handbook.com
Authors (Ralph Droms, Ted Lemon) of this book are authors of DHCP RFCs.

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.

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

Created attachment 400396 [details]
Test output

This is the test result of rebind send time error.
recvtime is a little out of range.

> 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

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

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

Verified in dhcp-4.1.1-13.fc12
Great job. Thanks.

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

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.

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.