Bug 574310 - dhclient SHOULD continue to use any IP addresses unless got reply of confirm msg
dhclient SHOULD continue to use any IP addresses unless got reply of confirm msg
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 574311 592162
  Show dependency treegraph
 
Reported: 2010-03-17 02:23 EDT by Yang Ren
Modified: 2011-06-03 06:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 574311 592162 (view as bug list)
Environment:
Last Closed: 2011-06-03 06:37:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Yang Ren 2010-03-17 02:23:54 EDT
Description of problem:
dhcp client should keep use ip address before it got the reply msg fro confirm msg.

During Confirm transmission client should keep the old information.

Version-Release number of selected component (if applicable):
dhcp-4.1.1-9.fc12

How reproducible:
Always

Steps to Reproduce:
1. start a client and got a ip from a dhcp server.
2. restart interface to force client send confirm msg.
3. Then send echo request msg to the client.

Actual results:
client did not reply echo request msg

Expected results:
client should reply echo request msg

Additional info:
Comment 1 Jiri Popelka 2010-03-23 06:56:43 EDT
Only information I found to this in RFC-3315
is the last paragraph of
18.1.2. (Creation and Transmission of Confirm Messages):

   If the client receives no responses before the message transmission
   process terminates, as described in section 14, the client SHOULD
   continue to use any IP addresses, using the last known lifetimes for
   those addresses, and SHOULD continue to use any other previously
   obtained configuration parameters.

This (as I understand it) says that client should keep using the old IP address
when the Confirm message transmission process terminates and no responses
were received.

I don't think the client should/can use the old IP address before the transmission process terminates. Because the sense of Confirm/Reply message exchange is to 
determine whether the address is still appropriate to the link to which the client is connected.

Correct steps are:
1. start a client and got a ip from a dhcp server.
2. shut-down server, so it doesn't send Reply's
3. restart interface to force client send confirm msg.
4. Wait for CNF_MAX_RD (10 seconds) (RFC3315, 5.5)
5. Send echo request msg to the client.

Client begins to use the old address whenever the Confirm message transmission process terminates (e.g. CNF_MAX_RD was reached) and no responses were received.

Actual results:
client replies to echo request message
Comment 2 Yang Ren 2010-03-23 22:39:27 EDT
> 
> Correct steps are:
> 1. start a client and got a ip from a dhcp server.
> 2. shut-down server, so it doesn't send Reply's
> 3. restart interface to force client send confirm msg.
> 4. Wait for CNF_MAX_RD (10 seconds) (RFC3315, 5.5)
> 5. Send echo request msg to the client.
> 
Yes your are right. The test step is just same as u said. 
I retest it in dhclient-4.1.1-11.fc12.x86_64 today
It passed. Got the echo reply from client.

It's wired that in dhclient-4.1.1-9.fc12.x86_64 all confirm msg test pass unless Reserved Address Information(can not got echo reply msg).
But in dhclient-4.1.1-11.fc12.x86_64 all confirm msg test failed because elapsed time not zero unless this test.

Just close this bug as NOTABUG. If I find this happen again I'll reopen.
Comment 3 Yang Ren 2010-04-15 02:50:23 EDT
I'd like to reopen this bug.
see bug #574679 

After I apply patch
Confirm message format	                              PASS
Retransmission of Confirm message                     PASS
Maximum Retransmission Time of Confirm message        PASS
Maximum Retransmission Duration of Confirm message    PASS
Reserved Address Information                          FAIL

what tahi patch do is after ifup interface send RA to nut whatever if nut send a RS or not.

Before I apply this patch
Confirm message format	                              FAIL
Retransmission of Confirm message                     FAIL
Maximum Retransmission Time of Confirm message        FAIL
Maximum Retransmission Duration of Confirm message    FAIL
Reserved Address Information                          PASS

All fail reason is elapsed-time is not zero. because it did not catch the first confirm message.

That means during the first three or four confirm message retransmission the old address is not reachable?

Can u have a look at this problem.
Comment 4 Jiri Popelka 2010-04-15 07:58:36 EDT
(In reply to comment #3)
> That means during the first three or four confirm message retransmission the
> old address is not reachable?

Test DHCP_CONF.1.2.4 : Transmission of Confirm message	
45	Part E : Reserved Address Information

*  Verification Points

     If the client receives no responses before the Confirm message 
     transmission process terminates,  the client SHOULD continue to 
     use any IP addresses, using the last known lifetimes for those 
     addresses.
       
That for me means that during the first three or four confirm message retransmission the old address is not reachable,
because the client begins to use the old address whenever the Confirm message transmission process terminates (e.g. CNF_MAX_RD was reached) and no responses were received.

See comment #1.
"I don't think the client can use the old IP address before the
transmission process terminates.
Because the sense of Confirm/Reply message exchange is to 
determine whether the address is still appropriate to the link to which the
client is connected."

In other words:
The old address can be reachable after CNF_MAX_RD from the first confirm message sent.
But the time when the address becomes reachable can be slightly longer than CNF_MAX_RD, because some time takes the process of DAD before the address can be used.
Comment 5 Yang Ren 2010-04-15 08:17:12 EDT
Got it. I'll think about it. reply here later.
Comment 6 Yang Ren 2010-04-16 02:05:18 EDT
I know what's the problem is now.

I retest confirm message part for several times.
The MRD test is also fail.

http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client_tp/rfc3315/44.html
It fail with reason:
"Current RD is 14.3625719547272 sec, MRD is 10
No retransmission was observed within MRD
NG"

RD > MRD that many because some time takes the process of DAD before the address can be used.
Maybe this is the problem make the test fail?


And also for this bug. The time is longer and tahi will immediate send echo request to old message when CNF_MAX_RD is reached.
http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client_tp/rfc3315/45.html

As u saide in comment 4:
"But the time when the address becomes reachable can be slightly longer than
CNF_MAX_RD, because some time takes the process of DAD before the address can
be used."

Can we make RD <= MRD

I think so that we can pass the test.
Comment 7 Jiri Popelka 2010-05-04 02:53:51 EDT
(In reply to comment #6)
> It fail with reason:
> "Current RD is 14.3625719547272 sec, MRD is 10
> No retransmission was observed within MRD NG"
> 
> RD > MRD that many because some time takes the process of DAD before the
> address can be used.
> Maybe this is the problem make the test fail?
Yes, it is.

> And also for this bug. The time is longer and tahi will immediate send echo
> request to old message when CNF_MAX_RD is reached.
> 
> As u said in comment 4:
> "But the time when the address becomes reachable can be slightly longer than
> CNF_MAX_RD, because some time takes the process of DAD before the address can
> be used."
> 
> Can we make RD <= MRD
> 
> I think so that we can pass the test.    
I can *not* make RD <= MRD (i.e. make the old address available before MRD is reached). We need to wait for MRD and if there's no response, we can make the old address available (and we should perform DAD before making it available).

RFC3315 says:
"The client SHOULD perform DAD on address before using that address for traffic."
So the test should count with the fact that the DAD needs some time (I my case it always takes 1-4 seconds) to perform.
Comment 8 Yang Ren 2010-05-17 03:11:52 EDT
I understand this situation. And I have send a mail to tahi mail list for discuss.
Comment 9 wang jiabo 2010-10-18 22:28:40 EDT
nobody take care the test script issue in TAHI and Ipv6ready so far. we have
two choice to do : one close the bug until tahi or ipv6ready fix their suite.
another continue waiting feedback from tahi or ipv6ready.
thanks
jiabo
Comment 10 Bug Zapper 2010-11-03 15:26:36 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Yang Ren 2010-11-03 23:04:34 EDT
I understand this properly is a bug in tahi test suit. We still got some failure about tahi dhcp test.  In order to allow other people know what we meet in tahi dhcp testing I keep this bug open. We always testing the nearest package So the version should not be a problem. 
So Jiri Should we close this bug?
Comment 12 Bug Zapper 2011-06-02 12:08:15 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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