Bug 592162

Clone this bug to rhel to record.
+++ This bug was initially created as a clone of Bug #574310 +++

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:

--- Additional comment from jpopelka on 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

--- Additional comment from ryang on 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.

--- Additional comment from ryang on 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.

--- Additional comment from jpopelka on 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.

--- Additional comment from ryang on 2010-04-15 08:17:12 EDT ---

Got it. I'll think about it. reply here later.

--- Additional comment from ryang on 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.

--- Additional comment from jpopelka on 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.