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.
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.
Created attachment 455582 [details] Patch This patch fixes the problem for me. It is a back-port (from dhcpv6-1.0.22) of these upstream changes: http://git.fedorahosted.org/git/?p=dhcpv6.git;a=commitdiff;h=ecf12eeca88b393f7d57253f0318caf8b0b9411a http://git.fedorahosted.org/git/?p=dhcpv6.git;a=commitdiff;h=6da6d77de6664e651110299a1b4ddc1c50cbe27c http://git.fedorahosted.org/git/?p=dhcpv6.git;a=commitdiff;h=c268ed205fe219095b855abeef9fadb1b1238e77
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.
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/
Closing per previous comment.