Bug 124022

Summary: dhclient does not work with custom-named network devices
Product: [Fedora] Fedora Reporter: Aaron Gaudio <madcap>
Component: dhcpAssignee: Jason Vas Dias <jvdias>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: mitr, orion, pierre-bugzilla, redhat
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: initscripts-7.60 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-09 18:57:45 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 129096    
Bug Blocks:    
Description Flags
Patch to apply to /etc/sysconfig/network-scripts/network-functions based on Teraya's changes none

Description Aaron Gaudio 2004-05-22 19:58:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040510 Galeon/1.3.12

Description of problem:
I have several network devices set up on my laptop that are named
differently from the physical ethernet address. For instance, network
device "Home" uses eth1, set up using the system-config-network utility.

dhclient does not recognize such names for network devices. Looking at
/sbin/dhclient-script, it expects to find an ifcfg-DEVICE file in
/etc/sysconfig/network-scripts, where DEVICE is the physical ethernet
device name ("eth1", for example). Therefore, dhclient will refuse to
continue, and attempting to bring the interface up fails.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Using system-config-network, add a network device named something
other than the physical ethernet device. Enable dynamic IP address for
this device.
2. Make sure you don't have another network device set up using the
physical ethernet device name.
3. Attempt to bring the device up.

Actual Results:  dhclient-script (run by dhclient) complains that it
cannot find the device configuration (e.g. "dhclient-script:
configuration for eth0 not found.") and fails. The network interface
does not come up.

Expected Results:  The network interface comes up and obtains an
address via dhcp.

Additional info:

Line 85 in /sbin/dhclient-script has this:


$interface is the physical device name, not the network device name as
set in system-config-network. The latter name does not appear to be
available in the environment variables.
Comment 1 Harald Hoyer 2004-05-24 06:33:46 EDT
reassigning to dhcp
Comment 2 Teraya 2004-05-31 14:55:20 EDT
This troubled me too.  I have a laptop with an onboard eth0, an eth1
in the docking station, but if not docked the wireless is eth1
(otherwise eth2).  Network profiles are the only thing to save me.   : )  

Here's what I just did today to get around the dhclient-script config

RPM initscripts-7.53-1
FILE /etc/sysconfig/network-scripts/network-functions

>     ## Added by Teraya to fix device aliases / profiles  20040531
>     CONFIG=`fgrep -il "DEVICE=${1}"
>     [ -f "${CONFIG}" ] && return
>     ## --end changes  20040531
Comment 3 Teraya 2004-05-31 14:57:24 EDT
Created attachment 100719 [details]
Comment 4 Aaron Gaudio 2004-07-05 13:26:57 EDT
This looks like a duplicate of bug 123034.
Comment 5 Aaron Gaudio 2004-07-05 13:35:41 EDT
I took Teraya's diff but modified it somewhat. The problem is that
fgrep and the given pattern will not distinguish between aliases
("DEVICE=eth1" will pick up not only an interface using "eth1" but
also any interfaces in the same profile using aliases of eth1). So, I
suggest using grep instead of fgrep, and using "DEVICE=${1}\$" as the
pattern instead. Unified diff attached.
Comment 6 Aaron Gaudio 2004-07-05 13:37:30 EDT
Created attachment 101639 [details]
Patch to apply to /etc/sysconfig/network-scripts/network-functions based on Teraya's changes
Comment 7 Miloslav Trmac 2004-07-05 13:54:49 EDT
*** Bug 123034 has been marked as a duplicate of this bug. ***
Comment 8 Jason Vas Dias 2004-08-03 20:17:25 EDT
dhclient will NOT work with pseudo-interfaces such as eth0:0 .

You should configure only your real devices (eg. eth0, eth1) to
use dhcp ; you can then configure pseudo-devices (eg. eth0:0) to
have static IP addresses, so that your machine will respond to
the same static IP address no matter what dhcp address is assigned.

Yes, the system-config-gui DOES create the
/etc/sysconfig/network-scripts/ifcfg-eth0:0 file (for example), 
(if you choose Apply and Save!) but that file is totally useless 
if it contains BOOTPROTO=dhcp - dhclient cannot operate with such
devices due to its basic design.

And should it? I think not. Only one Ethernet address (shared by
multiple pseudo-devices) can be assigned a unique IP address by DHCP.

So the bug is that system-config-gui lets you choose DHCP to configure
pseudo devices in the first place (bug 129096 raised).
Comment 9 Pierre Ossman 2004-08-04 03:40:33 EDT
We're not talking about pseudo-devices, we're talking about aliases
for devices. I.e. insted of calling eth0 ifcfg-eth0 I call it
ifcfg-work. I might then also have ifcfg-home to be able to have
different settings depending on where I am.

Using a wireless card on a laptop this is a must since you have to
change keys when you enter encrypted networks. Having an alias set up
for each net is great.

Having a ifcfg-<device> with a rather generic DHCP configuration works
most of the time since the dhclient scripts doesn't read many options.
It is still a bug though since it reads the wrong configuration.
Comment 10 Teraya 2004-08-04 23:48:09 EDT
This bug appears to have been closed in error.  As noted, the original
issue is not with pseudo-interfaces (eth0:0, eth0:1) but rather with
making alias names (like eth0-work, eth0-home) for your network
interfaces.  I'd like to see this bug re-opened.  
Comment 11 Jason Vas Dias 2004-08-09 18:55:31 EDT
 On further investigation, it appears this "initscripts" bug was
 fixed and is working in FC3 (rawhide).
 initscripts: 7.60 +
 dhcp:        3.0.1 

Comment 12 John Flanagan 2004-12-21 14:41:57 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.