The only failure shown now seems to be network-manager, which is failing its
'test_no_ap' test; that appears to have been failing for a while:
also there's a bug opened today for it:
The test log in that bug description shows the same failure, test_no_ap,
and the log shows the isc-dhcp installed package version is
4.3.5-3ubuntu2.2, which doesn't contain the change from this bug.
The other autopkgtest it's failing is the 'killswitches-no-urfkill'
test; it fails at this check:
if ! LC_MESSAGES=C nmcli radio wifi | grep -qc disabled; then
echo "ERROR: NM could not track device state."
This is failing because the test case is faulty; it's being tracked in this bug:
So I think we can ignore both these autopkgtest failures.
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
dhclient-script fails to wait for link-local address
Status in isc-dhcp package in Ubuntu:
Status in isc-dhcp source package in Trusty:
Status in isc-dhcp source package in Xenial:
Status in isc-dhcp source package in Zesty:
Status in isc-dhcp source package in Artful:
Status in isc-dhcp source package in Bionic:
Status in isc-dhcp package in Debian:
bug 1633479 made a change to isc-dhcp to wait for an interface's link-local
ipv6 address to switch from 'tentative' to normal, because all link-local
addresses briefly go through a 'tentative' state while the kernel is performing
ipv6 link-local 'duplicate address detection' (DAD). While in the 'tentative'
state, dhclient can't take over the interface and send out
dhcpv6 requests; it must wait until DAD completes.
However, the change made in that bug does not account for the case
where the 'tentative' check is done before the interface has even set
up a link-local address; its case statement assumes if there is no
'tentative' or 'dadfailed' string in the output, the link-local
address is ready to use. When the address check finds no address at
all, this will return as successful, even though it shouldn't, and
dhclient will fail to get the dhcpv6 address.
on a system that is configured for dhcpv6 on one or more of its
interfaces, repeatedly try to get the dhcpv6 address. For interfaces
that are slower to actually set up their initial tentative link-local
address, they will occasionally fail, since the current code is a race
between the kernel adding the tentative link-local address, and the
dhclient-script.linux code checking the interface for a tentative
with the patch to correct this, even interfaces slow to add their
tentative link-local address should correctly wait for the address to
get added, and then transition from tentative to normal, and then
begin the dhcpv6 process.
errors in this function can cause dhclient to fail to get a ipv6
address for an interface; regression would happen if this patch makes
it fail more than it already is failing, but would not cause other
failures or problems after getting an ipv6 address; this patch will
affect only startup-time.
additionally, the current behavior of dhclient when using an interface
that has no link-local address after being brought up is to exit
immediately; while after this patch dhclient will wait ~6 seconds
before exiting (while waiting for the interface to get a non-tentative
link-local addr). This is the point of this bug, that some NIC hw
doesn't show a tentative link-local addr immediately after coming up.
However, if dhclient -6 is configured to run on an interface without
any link state at all (e.g. its physical cable is unplugged), then
while before dhclient would exit immediately with error, it now waits
6 seconds. If the system is misconfigured like that, or if someone
pulls a cable and reboots, then system boot will be delayed an extra 6
seconds. However, that short delay for misconfigured/broken systems
seems acceptable to me, in exchange for allowing dhclient to work with
slightly slow NIC hw. Additionally, consider that if the problem is
instead no dhcpv6 server, dhclient -6 will wait a much, much longer
amount of time for a dhcpv6 response before giving up.
related bug 1633479
If a interface does not yet have a link-local address (as it may have
just been brought up), dhclient -6 <ifname> will fail. The built-in
"wait for link-local address" loop does not function properly, causing
In trying to configure isc-dhcp-client 4.3.5-3ubuntu1 for IPv6 on
Ubuntu 17.04, I was finding that on boot I was getting failures with
the logged message "no link-local IPv6 address for <ifname>"
I found that it took several seconds for the link-local address to be
assigned when the interface came up (in this case, the ISP/modem-
facing interface), and worked around it with a script that looks at
/sbin/ifconfig $IFACE | /bin/fgrep -q 'scopeid 0x20'
and loops for a fixed number of times for that to be successful.
On looking at /sbin/dhclient-script it appears that it *tries* to do
the same thing in
# set the link up and wait for ipv6 link local dad to finish
this code sets
out=$(ip -6 -o address show dev "$dev" scope link)
then checks it with a case statement inside of a loop for
case " $out " in
*\ dadfailed\ *)
error "$dev: ipv6 dad failed."
*\ tentative\ *) :;;
*) return 0;;
If there is no link-local address, $out will be empty. The default
case is taken, and the loop exits immediately:
$ echo "'$out'" ; case " $out " in
> *\ dadfailed\ *)
> echo "dadfailed"
> *\ tentative\ *)
> echo "tentative"
> echo "default"
As a result, there is no "wait for link-local address" and when there
is no link-local address, dhclient fails later on.
Adding "the missing case" for "no address" case that continues the
loop is one possible solution.
. case " $out " in
. *\ dadfailed\ *)
. error "$dev: ipv6 dad failed."
. return 1;;
. *\ tentative\ *) :;;
+ " ")
. *) return 0;;
At least in my situation, this prevents the failure of dhclient due to
the link-local address not being "ready" yet.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~touch-packages
Post to : email@example.com
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp