Bug 1263466 - DHCPv6 + SLAAC fails; Can't bind to dhcp address: Cannot assign requested address
DHCPv6 + SLAAC fails; Can't bind to dhcp address: Cannot assign requested add...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp (Show other bugs)
6.7
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 16:53 EDT by Amy Farley
Modified: 2016-06-07 07:30 EDT (History)
4 users (show)

See Also:
Fixed In Version: dhcp-4.1.1-50.P1.el6
Doc Type: Bug Fix
Doc Text:
Cause Sometimes when DHCPv6 client is started in stateless mode (i.e. with '-6 -S' command line options) on network interface which is not fully "up". Consequence dhclient fails to run, because network interface does not have link-local address yet, which is needed for DHCPv6 client. Fix A wait loop was added into dhclient-script. Result dhclient doesn't fail due to missing link-local address.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 16:52:05 EDT
Type: Bug
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 Amy Farley 2015-09-15 16:53:01 EDT
Description of problem:
Running with stock 6.7 out of the box, so using dhclient-4.1.1-49.P1.el6.x86_64.rpm. NetworkManager is disabled.

Bringing the interface up fails with "Determining IPv6 information for eth0... failed."

/var/log/messages shows:
dhclient[3650]: Can't bind to dhcp address: Cannot assign requested address

If they revert to to previous dhclient:
rpm -U dhclient-4.1.1-38.P1.el6.x86_64.rpm --force --nodeps; then bringing up the interface succeeds with "RTNETLINK answers: File exists; Determining IPv6 information for eth0... done.

Version-Release number of selected component (if applicable): dhclient-4.1.1-49.P1.el6.x86_64


How reproducible:
100% in 2 different PCs, 2VMs under ESXi

This was tested on 4 different systems, and is 100% reproducible. 
dhclient-4.1.1-49.P1 - 100% Fail
dhclient-4.1.1-38.P1 - 100% Pass
dhclient-4.1.1-49.P1 with Patch 55 commented - 100% Pass

Steps to Reproduce:
1. setup config: 
Configured eth0 with DHCPv6 + SLAAC:
DEVICE=eth0
ONBOOT=no
BOOTPROTO=none
IPV6INIT=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-S

2. Bring up interface

3. Fails with "Determining IPv6 information for eth0... failed."

Actual results:

/var/log/messages shows:
dhclient[3650]: Can't bind to dhcp address: Cannot assign requested address

Expected results:


Additional info: refer to salesforce case# 01506489
Comment 2 Jiri Popelka 2015-09-17 10:31:14 EDT
Thanks for narrowing that problem down to the exact change (Patch55).

I have an idea what's going on here.
It seems to be bug #1130804, but this time for stateless DHCPv6 client.
We fixed bug #1130804 by putting [1] a sleep-loop into dhclient-script, which ensures that the link-local address is ready (not in tentative state).
That's been necessary after fixing bug #1001742 with Patch55, because that patch makes dhclient (v6) bind to the specified interface (its link-local address) instead of all interfaces.

Problem is that the stateless (v6) dhclient doesn't AFAIK run dhclient-script, so the fix for bug #1130804 has actually fixed only stateful v6 dhclient.

Not sure what can be done to fix it also for stateless v6 dhclient (since it doesn't run dhclient-script), but I'll try to find something.

[1] http://pkgs.devel.redhat.com/cgit/rpms/dhcp/commit/?h=rhel-6.7&id=77cbac5a334ef0e56f4baa864a590ea174cfc003
Comment 3 Jiri Popelka 2015-09-17 10:45:58 EDT
Quick & dirty work-around could be to put a 'sleep 3' into 
/etc/sysconfig/network-scripts/ifup-eth
before the
if /sbin/dhclient -6 -1 ${DHCPV6C_OPTIONS} ...
line (approx. 307)
Comment 4 Jiri Popelka 2015-09-22 11:39:46 EDT
Fixed upstream (Fedora) with:
http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?id=59c88cb2ffee720ed251e267c1deec615872d9c2
Comment 5 Amy Farley 2015-09-22 11:41:31 EDT
Customer was unable to update in bz, this is his response to the case:

Hi,

My logins don't allow me to log in to comment on the bug directly, so I'll have to responds to Jiri's comments here:


>> It seems to be bug #1130804, but this time for stateless DHCPv6 client.
That's exactly what I have found. I thought the fix to #1130804 was the fix for my problem, and went to upgrade but found that I already had that fix.

>> Problem is that the stateless (v6) dhclient doesn't AFAIK run dhclient-script, so the fix for bug #1130804 has actually fixed only stateful v6 dhclient.
Correct. Setting stateless diverts the code path and thus does not hit the code which uses dhclient-script.

>> Quick & dirty work-around could be to put a 'sleep 3' into /etc/sysconfig/network-scripts/ifup-eth
A "sleep 3" works, but it's a very difficult workaround for us due to legal/security concerns and the resulting processes on our end. We really need the fix in an RH released RPM.
Comment 6 Jiri Popelka 2015-09-22 11:48:55 EDT
There are testing packages (el6, x86_64) with the fix included:
https://jpopelka.fedorapeople.org/dhcp/bz1263466

Anybody, feel free to provide feedback.
Comment 13 errata-xmlrpc 2016-05-10 16:52:05 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0803.html

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