touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #72099
[Bug 1446767] Re: dhclient can fail if other nics are renamed
** Description changed:
+ === 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/rules.d/70-persistent-net.rules.
+
+ 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/interfaces for dhcp on that interface
+ $ grep eth0 /etc/network/interfaces
+ 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.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
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://www.isc.org/software/dhcp/
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
ProcVersionSignature: User Name 3.19.0-15.15-generic 3.19.3
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_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: isc-dhcp
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1446767
Title:
dhclient can fail if other nics are renamed
Status in isc-dhcp package in Ubuntu:
Confirmed
Status in isc-dhcp source package in Trusty:
Confirmed
Status in isc-dhcp source package in Vivid:
Confirmed
Status in isc-dhcp source package in w-series:
Confirmed
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/rules.d/70-persistent-net.rules.
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/interfaces for dhcp on that interface
$ grep eth0 /etc/network/interfaces
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.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
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://www.isc.org/software/dhcp/
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
ProcVersionSignature: User Name 3.19.0-15.15-generic 3.19.3
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_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: isc-dhcp
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1446767/+subscriptions
References