Bug 644460 - DHCPv6 Server Assigns Seemingly Random IP to SLES11 Client and then generates NotOnLink Error
DHCPv6 Server Assigns Seemingly Random IP to SLES11 Client and then generates...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
5.5
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
: Patch
Depends On:
Blocks: 668957 743405
  Show dependency treegraph
 
Reported: 2010-10-19 13:43 EDT by Bryan Mason
Modified: 2013-04-03 04:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-03 04:36:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch (5.30 KB, patch)
2010-10-25 13:04 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
Description Bryan Mason 2010-10-19 13:43:29 EDT
Description of problem:

    The DHCPv6 server in RHEL 5.5 seems to be assigning a random
    IPv6 address to SLES 11 clients.  This random address is then
    treated as an error becuase the address is NotOnLink.

Version-Release number of selected component (if applicable):

    dhcpv6-1.0.10-18.el5

How reproducible:

    100% in customer's environment

Steps to Reproduce:

    1. Configure DHCPv6 server on RHEL 5.5
    2. Attempt to get IPv6 address on SLES 11 client.
  
Actual results:

    DHCPv6 server fails to assign an address.

Expected results:

    Client should be able to get IPv6 address.

Additional info:

    The client is not requesting a particular IA Address.  However, in
    dhcp6_create_addrlist(), it seems that TAILQ_FIRST(reply_list) is
    not returning null, so we end up running addr_on_segment() on some
    random address.  The debug log shows the following:

        received solicit from fe80::221:5eff:fef0:594%eth0
        checking address ba17:b9bf:9f2b:0:62ae:d9bf:9f2b:0 on segment
        ba17:b9bf:9f2b:0:62ae:d9bf:9f2b:0 address not on link

        received request from fe80::221:5eff:fef0:594%eth0
        checking address fd17:b9bf:9f2b:0:60aa:d9bf:9f2b:0 on segment
        fd17:b9bf:9f2b:0:60aa:d9bf:9f2b:0 address not on link

        received solicit from fe80::221:5eff:fef0:594%eth0
        checking address ba17:b9bf:9f2b:0:6ec6:d9bf:9f2b:0 on segment
        ba17:b9bf:9f2b:0:6ec6:d9bf:9f2b:0 address not on link

        received request from fe80::221:5eff:fef0:594%eth0
        checking address fd17:b9bf:9f2b:0:6cc2:d9bf:9f2b:0 on segment
        fd17:b9bf:9f2b:0:6cc2:d9bf:9f2b:0 address not on link

        received solicit from fe80::221:5eff:fef0:594%eth0
        checking address ba17:b9bf:9f2b:0:6abe:d9bf:9f2b:0 on segment
        ba17:b9bf:9f2b:0:6abe:d9bf:9f2b:0 address not on link

        received request from fe80::221:5eff:fef0:594%eth0
        checking address fd17:b9bf:9f2b:0:68ba:d9bf:9f2b:0 on segment
        fd17:b9bf:9f2b:0:68ba:d9bf:9f2b:0 address not on link

        received solicit from fe80::221:5eff:fef0:594%eth0
        checking address ba17:b9bf:9f2b:0:66b6:d9bf:9f2b:0 on segment
        ba17:b9bf:9f2b:0:66b6:d9bf:9f2b:0 address not on link

        received request from fe80::221:5eff:fef0:594%eth0
        checking address fd17:b9bf:9f2b:0:64b2:d9bf:9f2b:0 on segment
        fd17:b9bf:9f2b:0:64b2:d9bf:9f2b:0 address not on link

        received solicit from fe80::221:5eff:fef0:594%eth0
        checking address ba17:b9bf:9f2b:0:62ae:d9bf:9f2b:0 on segment
        ba17:b9bf:9f2b:0:62ae:d9bf:9f2b:0 address not on link

        received request from fe80::221:5eff:fef0:594%eth0
        checking address fd17:b9bf:9f2b:0:60aa:d9bf:9f2b:0 on segment
        fd17:b9bf:9f2b:0:60aa:d9bf:9f2b:0 address not on link

    The tcpdumps show that the client is _not_ including an IA Address
    in its IA_NA request, so I don't know where those addresses are
    coming from.  All the addresses differ in the fourth group, so
    these addresses seem somewhat random.

    I've checked back through the code to see if reply_list or
    req_list wasn't being initialized properly, but I couldn't find
    any obvious problems.

    The SLES 11 client is running dhcpv6-1.0.22-3.14.

    The netdumps and log files will be attached shortly.
Comment 5 Jiri Popelka 2010-10-25 10:31:52 EDT
I was able to reproduce this problem with dhcpv6-1.0.22 from Fedora-10.

I found out that this "random IP" problem is fixed by this upstream change
http://git.fedorahosted.org/git/?p=dhcpv6.git;a=commitdiff;h=6da6d77de6664e651110299a1b4ddc1c50cbe27c

But it seems that we need also some other commit, because
when I apply only this one, the server then ignores Confirm messages
and to Renew message responds with Reply without IA, which
makes the client sending other Renew messages.
Comment 11 RHEL Product and Program Management 2011-05-31 09:53:34 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Product and Program Management 2011-09-22 20:23:17 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 13 RHEL Product and Program Management 2012-06-11 21:14:24 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 14 Jiri Popelka 2013-03-05 11:03:37 EST
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5.
Since phase 2 we'll be addressing only security and critical issues.
I'm raising 5.10 flag but given that we haven't fixed this in previous minor releases I doubt this will ever be fixed.
Bryan, what about closing this right now ? The customer seems to be happy running the test packages and it doesn't bother anyone else, does it ?

[1] https://access.redhat.com/support/policy/updates/errata/
Comment 16 Jiri Popelka 2013-04-03 04:36:40 EDT
Closing per previous comment.

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