Description of problem: dhclient now will retransmission request release declient msg beyond MRC In the test MRC is defferent between different msg type. For request msg REQ_MAX_RC = 10 For release msg REL_MAX_RC = 5 for declient msg DEC_MAX_RC = 5 I'm not sure the count fit rfc. BTW: And this problem is may also occur in confirm msg. Version-Release number of selected component (if applicable): dhclient-4.1.1-13.fc12 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: server will retransmission request release declient beyond MRC Expected results: server should stop retransmission request release declient if reach MRC Additional info:
(In reply to comment #0) > Description of problem: > dhclient now will retransmission request release declient msg beyond MRC > In the test MRC is defferent between different msg type. > For request msg > REQ_MAX_RC = 10 > For release msg > REL_MAX_RC = 5 > for declient msg > DEC_MAX_RC = 5 I did test this and my results are: Request msg (REQ_MAX_RC = 10): - client sent 11 (1 transmission + 10 retransmissions) Request messages Release msg (REL_MAX_RC = 5): - client sent 6 (1 transmission + 5 retransmissions) Release messages Decline msg (DEC_MAX_RC = 5): - client sent 6 (1 transmission + 5 retransmissions) Decline messages What were your exact results (retransmission counts) ? I actually also noticed this "problem" when I was implementing the sending of Decline message (bug #559147). So I was studying the section 14. of RFC 3315 There's paragraph, saying: " MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times." This is important, but for me also confusing. I don't know if the description (section 14) differs between transmission and *re*transmission. From the first sentence it seems that MRC is count of only *re*transmissions (so the first transmission is not counted). In that case the client should send e.g Release msg 1 (transmission) + REL_MAX_RC (retransmissions) = 6 times. Which is how it works now (according to my tests). From the second sentence it seems that MRC is count of all transmissions (including the first). In that case the client should send e.g. Release msg REL_MAX_RC = 5 times. Which is probably how TAHI want it to work. I know that this is only playing with words, but that paragraph is really confusing for me. > BTW: And this problem is may also occur in confirm msg. I think it can't, because: "Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times." MRC for Confirm messages is zero. > Version-Release number of selected component (if applicable): > dhclient-4.1.1-13.fc12 Yang, do you remember if you saw this problem also with dhclient prior to 4.1.1-13.fc12 ? I just want to be sure, that this problem is not caused by fixing the bug #559153. > Actual results: > server will retransmission request release declient beyond MRC > > Expected results: > server should stop retransmission request release declient if reach MRC > > Additional info: RFC 3315 section 14. Reliability of Client Initiated Message Exchanges section 5.5. Transmission and Retransmission Parameters
To sum up my previous (chaotic) comment: The question is whether the MRC defines Maximum retransmission count or Maximum transmission count. Now the message exchange stops once the client has *re*transmitted (repeated the transmission) the message MRC times. TAHI test probably want it to stop once the client has transmitted the message MRC times. Am I correct Yang ?
Yes u r right. http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/40.html The MRC for the first request msg is 10. And when it receive second request msg it said "Retransmission Count is 2." So I think we can pass it by just retry (REQ_MAX_RC - 1) time but it may not correct. According rfc I think your action is right. MRC is the maximum retransmission and REQ_MAX_RC is max request retry attempts. That should means it will retry REQ_MAX_RC time. I'd like to send a mail to tahi list to know their opinion.
>Yang, do you remember if you saw this problem also with dhclient prior to >4.1.1-13.fc12 ? I just want to be sure, that this problem is not caused by >fixing the bug #559153. this problem also occur in previous version. So I think it's not the problem about that fix. And comfirm may still have some problem in RT or RD. But before solve the elapsed time problem I can not make sure they are bugs. I still waitting tahi guys to give me the explain about how their test case can not recognize the first confirm msg.
Created attachment 403947 [details] Patch to satisfy TAHI test (In reply to comment #3) > The MRC for the first request msg is 10. > And when it receive second request msg it said "Retransmission Count is 2." > So I think we can pass it by just retry (REQ_MAX_RC - 1) time but it may not > correct. > According rfc I think your action is right. MRC is the maximum retransmission > and REQ_MAX_RC is max request retry attempts. That should means it will retry > REQ_MAX_RC time. > > I'd like to send a mail to tahi list to know their opinion. The patch needed to pass this test is very easy, but there's still question if we really need it. Did you ask the tahi list ? Or do you want me to make a new build with this patch ?
Already sent a mail to ask. Do not got one reply. I think we did not make a new build. Pass tahi test suite is good. But That may make our software failed on other test. I'll update the reply here after tahi reply me.
Confirmed with tahi mail list. Our behavior is right they will correct the test cases. I'll closed this bug with NOTABUG. http://www.tahi.org/users/mail-list/201004.month/1614.html
Thanks Yang, this thread http://www.ietf.org/mail-archive/web/dhcwg/current/msg08052.html answers what I was asking in comment #1 and comment #2.