Bug 365501 - TAHI--DHCPv6--The Time field of the recieved DHCPv6 Advertise Message is unmatched
TAHI--DHCPv6--The Time field of the recieved DHCPv6 Advertise Message is unma...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
5.0
All Linux
urgent Severity medium
: rc
: ---
Assigned To: David Cantrell
Martin Jenner
: ZStream
: 436787 (view as bug list)
Depends On:
Blocks: 253764 455665
  Show dependency treegraph
 
Reported: 2007-11-04 00:52 EDT by Zhiyong Wu
Modified: 2009-01-20 16:38 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:38:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zhiyong Wu 2007-11-04 00:52:16 EDT
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
Comment 1 RHEL Product and Program Management 2007-11-07 05:34:58 EST
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.
Comment 3 Zhiyong Wu 2007-12-28 00:50:00 EST
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
Comment 4 Zhiyong Wu 2007-12-28 01:17:08 EST
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

Comment 5 David Cantrell 2008-01-15 23:20:59 EST
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.
Comment 7 Zhiyong Wu 2008-02-22 01:53:54 EST
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
Comment 9 Denise Dumas 2008-02-27 10:21:45 EST
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. 
Comment 11 David Cantrell 2008-03-12 16:15:09 EDT
Fixed in dhcpv6-1.0.10-2.el5.
Comment 13 David Cantrell 2008-03-14 15:51:35 EDT
*** Bug 436787 has been marked as a duplicate of this bug. ***
Comment 19 Red Hat Bugzilla 2008-07-07 21:24:14 EDT
Adding yshao@redhat.com to the cc list as the manager of the disabled user zwu@redhat.com who reported this bug
Comment 20 David Cantrell 2008-07-15 15:26:09 EDT

*** This bug has been marked as a duplicate of 439526 ***
Comment 21 David Cantrell 2008-07-15 19:21:18 EDT
A patch for this issue is included in dhcpv6-1.0.10-6.el5 and later builds.
Comment 22 Jiri Skrabal 2008-07-16 17:00:33 EDT
Changing the priority to urgent because of EUS
Comment 28 David Cantrell 2008-09-16 17:08:57 EDT
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.
Comment 31 David Cantrell 2008-10-07 19:47:32 EDT
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.
Comment 37 Mitsuru Chinen 2008-11-27 05:36:55 EST
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.
Comment 38 errata-xmlrpc 2009-01-20 16:38:09 EST
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

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