dhclient can fail if other nics are renamed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
isc-dhcp (Fedora) |
Fix Released
|
Low
|
|||
isc-dhcp (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Unassigned | ||
Vivid |
Fix Released
|
High
|
Unassigned | ||
Wily |
Fix Released
|
High
|
Unassigned |
Bug Description
=== Begin SRU Information ===
[Impact]
Systems that use dhcp for network config combined with network device re-naming can hit a race condition in dhclient which causes dhcp to fail. Any network device renaming could cause this, but the most likely scenario is boot with udev persistent naming in /etc/udev/
This can be a fatal error when network devices that are required for proper function.
[Test Case]
To recreate the failure:
* boot an ubuntu system with an interface that can dhcp
* configure /etc/network/
$ grep eth0 /etc/network/
auto eth0
iface eth0 inet dhcp
* run attached 'nic-go-crazy' as root in one window/shell
this will create by default 10 tuntap devices and repeatedly rename them.
* run attached 'ifup-loop eth0'
ifup-loop will exit failure if dhclient failed to bring the network up.
With the fix provided, this will/should run indefinitely.
[Regression Potential]
Chance for regression here should be reasonably small. However, a very significant number of systems run dhclient, so any change has to be considered risky.
One thing to note, is that Fedora has carried this patch for > 3 years.
Per getifaddrs(3):
| The getifaddrs() function first appeared in glibc 2.3, but before glibc
| 2.3.3, the implementation supported only IPv4 addresses; IPv6 support
| was added in glibc 2.3.3. Support of address families other than IPv4
| is available only on kernels that support netlink.
These versions are older than any supported Ubuntu release, so that should not be a problem.
=== End SRU Information ===
given 3 nics eth0, eth1, eth2
dhclient -1 -v -pf /run/dhclient.
while that in its early phases, if eth1 is renamed a race condition can cause dhclient to exit failure.
This can happen in real life when udev and persistent rules are used. Ie, in a system where eth0 is configured for 'auto' and dhcp and persistent rules cause renaming of devices during boot.
I have set up recreate of that more complex system lp:~smoser/+junk/lp1444428 , but this recreate is simpler to catch.
example, while running attached 'nic-go-crazy' on other nics, I try ifup eth1
$ sudo ifup eth1
sudo: unable to resolve host ubuntu
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https:/
Error getting interface address for 'nic0317610'; No such device
Error getting interface information.
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.
Failed to bring up eth1.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: isc-dhcp-client 4.3.1-5ubuntu2
ProcVersionSign
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
Date: Tue Apr 21 16:35:10 2015
DhclientLeases:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: isc-dhcp
UpgradeStatus: No upgrade log present (probably fresh install)
description: | updated |
tags: | added: patch |
description: | updated |
Changed in isc-dhcp (Fedora): | |
importance: | Unknown → Low |
status: | Unknown → Fix Released |
The solution here was pulled from https:/ /bugzilla. redhat. com/show_ bug.cgi? id=449946
The patch really just makes linux use getifaddrs rather than reading /proc/net/dev for information.
The change has been in place in fedora for ~ 3 years, so that should stand as some testimony.