Description of problem: When we have a DHCPv6's RFC3315 test about "Part B : DUID based on Link- layer Address Plus Time [DUID-LLT] Consistency" in the server mode, we found that the Time field of the recieved DHCPv6 Advertise Message is unmatched in some scenarios. Version-Release number of selected component (if applicable): kernel-2.6.18-43.el5 Software Environment: Testee(NUT): RHEL5 Kernel:2.6.18-43.el5 Tester(TN): FreeBSD6.2 DHCPv6_Self_Test_P2_1_0_7.tar.gz How reproducible: every time Steps to Reproduce: 1. Configure TAHI test environment. 2. Run the TAHI test suite 3. After the test completes, check for the results Actual results: The Time field of the recieved DHCPv6 Advertise Message is unmatched. Expected results: The Time field of the recieved DHCPv6 Advertise Message should be matched. Additional info: when NUT is set to the server mode, please refer to the url below: http://focus.brisbane.redhat.com/~zwu/dhcp_server/20071101/DHCPv6_Self_Test_P2_ 1_0_7_server/rfc3315/index.html (1) 15 Part B : DUID based on Link-layer Address Plus Time [DUID-LLT] Consistency
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
but another similar problem occur, The Time field of the recieved DHCPv6 Reply Message is unmatched when NUT is set to the server mode, please refer to the url below: http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071225/DHCPv6_Self_Test_P2_1_0_8_server/rfc3736/index.html (1) 10 Part B : DUID based on Link-layer Address Plus Time [DUID-LLT] Consistency
when NUT is set to the server mode, please refer to the url below: http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071225/DHCPv6_Self_Test_P2_1_0_8_server/rfc3736/index.html (1) 15 Part B : DUID based on Link-layer Address Plus Time [DUID-LLT] Consistency
I think I found it. The DUID type 1 time field was set to an arbitrary time in the year 2000. I've changed it to be a standard POSIX time value. Fixed upstream and will be in dhcpv6-1.0.5.
the test cases still FAIL On RHEL5.2 with dhcpv6-1.0.10 for more details, pls refer to http://focus.brisbane.redhat.com/~zwu/RHEL5.2-Server-20080212.0/20080220/DHCPv6_Self_Test_P2_1_0_8_server_1.0.10/rfc3315/index.html
In order to debug this problem, we need the test case for RHEL 5.2 with an exact reproducer, including output with verbose debugging messages from the DHCPV6 software. One way to do this would be to extract the commands that TAHI runs. The man pages for dhcp6s, dhcp6r, and dhcp6c all show how to generate verbose debug messages.
Fixed in dhcpv6-1.0.10-2.el5.
*** Bug 436787 has been marked as a duplicate of this bug. ***
Adding yshao to the cc list as the manager of the disabled user zwu who reported this bug
*** This bug has been marked as a duplicate of 439526 ***
A patch for this issue is included in dhcpv6-1.0.10-6.el5 and later builds.
Changing the priority to urgent because of EUS
I think this bug was caused by the same problem in bug #377101. A fix for that bug will be in dhcpv6-1.0.10-8.el5, so moving this one to MODIFIED.
This should be fixed with the patch for bug #377101 since the same code path is executed for this one. Moving to MODIFIED. Fix will be in dhcpv6-1.0.10-10.el5.
David, As I described at Bug #426899 and Trac of dhcpv6 upstream, this issue came the remote script bug. dhcpv6-1.0.10-duid_match_llt.patch is not necessary. You may think it is not necessary to revert the patch if all of the DHCPv6 conformance test get PASS. However, there is a possibility where the patch causes troubles. +duid_match_llt(struct duid *client, struct duid *server) +{ + struct dhcp6_duid_type1 *client_duid = NULL; + struct dhcp6_duid_type1 *server_duid = NULL; + + server_duid = (struct dhcp6_duid_type1 *) server->duid_id; + client_duid = (struct dhcp6_duid_type1 *) client->duid_id; + + if (server_duid != NULL && client_duid != NULL) { + server_duid->dh6duid1_time = client_duid->dh6duid1_time; + } else { + return -1; + } + + return 0; +} Your code assumes the client use DUID-LLT only as the Client ID. However, client may use the other type of DUID; DUID-EN, DUID-LL or new DUID which will be defined by the future RFC. On those DUID, "client_duid->dh6duid1_time" accesses wrong location of the memory. In the worst case, dhcp6s would cause SEGV.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0165.html