Bug 578064 - Max Retransmission count error in request|release|declient msg
Max Retransmission count error in request|release|declient msg
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 578066
  Show dependency treegraph
 
Reported: 2010-03-30 02:30 EDT by Yang Ren
Modified: 2010-04-12 05:13 EDT (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)
Patch to satisfy TAHI test (2.73 KB, patch)
2010-04-01 07:10 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.