Hello Eloy, or anyone else affected, Accepted ifupdown into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ifupdown/0.8.10ubuntu1.3 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: ifupdown (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1447715 Title: dhclient -6: Can't bind to dhcp address: Cannot assign requested address Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Xenial: Fix Committed Status in ifupdown package in Debian: Fix Released Bug description: [Impact] When using dhcpv6 configured via ifupdown, the interface's dhcp client fails to start at boot with the error: Can't bind to dhcp address: Cannot assign requested address This is because ifupdown doesn't wait, after bringing the interface up, for it to complete its link-local Duplicate Address Detection (DAD), and the dhcp client can't bind to the link-local address because it's still in "tentative" state (until DAD completes). This is fixed upstream in debian ifupdown in version 0.8.11 by adding '-tentative' to the /lib/ifupdown/wait-for-ll6.sh script; before the script was only waiting for the link-local address to appear, now it waits until the link-local address appears and is not in 'tentative' state. [Test Case] Original test case, before dhclient was fixed: Configure an interface, using ifupdown, with dhcpv6 (e.g. iface eth0 inet6 dhcp) and reboot. It will fail to get a dhcp address during boot. New test case, showing failure when using dhclient in 'stateless' mode: Configure ifupdown like: auto eth0 iface eth0 inet6 auto dhcp 1 When eth0 is down, run 'sudo ifup eth0', and it will fail as dhclient fails to start on the interface. [Regression Potential] As this modifies the wait-for-dad function, its potential for regression is to introduce failures in starting dhclient, possibly by failing to wait for DAD to complete or due to some other failure in the wait for dad function. [Other Info] After upgrading to Ubuntu 15.04 my computer is unable to obtain an IPv6 address via DHCPv6. The root cause is that dhclient is exiting with the following message: ----------------------------------------------------- Can't bind to dhcp address: Cannot assign requested address Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you are not running HP JetAdmin software, which includes a bootp server. If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging.. exiting. ----------------------------------------------------- The problem seems to exist in isc-dhcp-client 4.3.1-5ubuntu2 (15.04 version) because downgrading to isc-dhcp-client 4.2.4-7ubuntu14 (14.10 version) allows me to obtain an address. NetworkManager is the one launching dhclient. The two invocations (one for IPv4 and one for IPv6) are: dhclient_start(): running: /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d /network-manager.dhclient-eth0.pid -lf /var/lib/NetworkManager /dhclient-c0a3dfde-5c0b-4cef-9c3b-563cfb1fb9d2-eth0.lease -cf /var/lib/NetworkManager/dhclient-eth0.conf eth0 dhclient_start(): running: /sbin/dhclient -d -q -6 -N -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d /network-manager.dhclient6-eth0.pid -lf /var/lib/NetworkManager/dhclient6-c0a3dfde-5c0b-4cef-9c3b- 563cfb1fb9d2-eth0.lease -cf /var/lib/NetworkManager/dhclient6-eth0.conf eth0 I do not see anything suspicious with the way both dhclients are invoked. Given that a downgrade allows me to obtain an IPv6 address I think this might be a bug in the ISC DHCP client rather than in NetworkManager. Related Bugs: * bug 1633479: dhclient does not wait for ipv6 dad (duplicate address detection) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1447715/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
