This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes

Bug 578064

Summary: Max Retransmission count error in request|release|declient msg
Product: [Fedora] Fedora Reporter: Yang Ren <ryang>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: jpopelka, llim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 578066 (view as bug list) Environment:
Last Closed: 2010-04-12 04:43:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 578066    
Attachments:
Description Flags
Patch to satisfy TAHI test none

Description Yang Ren 2010-03-30 02:30:25 EDT
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:
Comment 1 Jiri Popelka 2010-03-30 09:37:39 EDT
(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
Comment 2 Jiri Popelka 2010-03-30 09:41:40 EDT
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 ?
Comment 3 Yang Ren 2010-03-30 22:28:42 EDT
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.
Comment 4 Yang Ren 2010-03-30 22:33:15 EDT
>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.
Comment 5 Jiri Popelka 2010-04-01 07:10:35 EDT
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 ?
Comment 6 Yang Ren 2010-04-01 22:08:43 EDT
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.
Comment 7 Yang Ren 2010-04-12 04:43:59 EDT
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
Comment 8 Jiri Popelka 2010-04-12 05:13:58 EDT
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.