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:
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
> > 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.
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.
(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.
Got it. I'll think about it. reply here later.
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.
(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.
I understand this situation. And I have send a mail to tahi mail list for discuss.
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
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
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?
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