Bug 208735

Summary:

wireless network interface naming unpredictable

Product:

[Fedora] Fedora

Reporter:

Bernard Johnson <bjohnson>

Component:

initscripts

Assignee:

Bill Nottingham <notting>

Status:

CLOSED NOTABUG

QA Contact:

Brock Organ <borgan>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

rawhide

CC:

rvokal

Target Milestone:

---

Target Release:

---

Hardware:

i386

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-10-02 16:59:21 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
ifcfg-eth0	none
ifcfg-lo	none

Description Bernard Johnson 2006-10-01 07:47:59 UTC

Description of problem:
The naming of the wireless network interface (normally eth1) is unpredictable. 
In previous releases, the interface would be named either eth1 or devxxxxxx
(x=numbers).  It seems that problem has been fixed (bugzilla #188955).  However,
on my system a new problem has developed.  The deviced is not intermittently
named __tmpxxxxxxxxxx (x=numbers).

When the deviced is named __tmpxxxxxxxxxx, NetworkManager is unable to start the
device:
Oct  1 01:23:15 localhost NetworkManager: <information> DHCP daemon state is now
12 (successfully started) for interface __tmp1804289383 
Oct  1 01:23:15 localhost NetworkManager: <information> DHCP daemon state is now
1 (starting) for interface __tmp1804289383 
Oct  1 01:23:15 localhost dhclient: Bind socket to interface: No such device

When the device is properly named eth1, the network will be activated normally.

Version-Release number of selected component (if applicable):
udev-095-10
initscripts-8.43-1
NetworkManager-0.6.4-5.fc6

How reproducible:
Sometimes.  Seems to happen more frequently after a "reboot" command is issued.

Steps to Reproduce:
1. Boot system
2. Observe interface name by /sbin/ifconfig
3.
  
Actual results:
If device is named __tmpxxxxxxxxxx, NetworkManager will not be able to start the
device.

Expected results:
A predictable interface name and a working NetworkManager.

Additional info:
If NetworkManager is simply not able to work with this name, it's probably a bug
in NetworkManager as well, however, I suspect deeper underlying problems related
to the interface naming.

Comment 1 Bill Nottingham 2006-10-02 13:50:58 UTC

Can you attach your /etc/sysconfig/network-scripts/ifcfg-* files?

Comment 2 Bernard Johnson 2006-10-02 15:48:47 UTC

Created attachment 137555 [details]
ifcfg-eth0

Comment 3 Bernard Johnson 2006-10-02 15:49:21 UTC

Created attachment 137556 [details]
ifcfg-lo

Comment 4 Bernard Johnson 2006-10-02 15:50:50 UTC

There is no ifcfg-eth1 file.

Comment 5 Bill Nottingham 2006-10-02 16:59:21 UTC

You need an ifcfg-ethX file for each interface, with the proper HWADDR added -
otherwise if the modules are loaded in reverse order, there's no way to know
what to name the one that's occupying eth0 when it shouldn't.

Comment 6 Bernard Johnson 2006-10-02 17:39:08 UTC

Bill, I guess I'd like some clarification on two points:

1) eth0 is always eth0.  eth1 is sometimes eth1 and sometimes __tmpxxxxxxxxxx. 
There is nothing occupying eth1, it just doesn't get named properly.  This would
imply that there is a reason other than the name being already used for it not
getting renamed.  However, you are right that creating the ifcfg-eth1 file fixes
this problem.

2) Shouldn't /some component/ take care of creating the ifcfg-eth1 automatically
since it seems to be integral to having the (wireless) system work correctly? 
If it requires a RFE, let me know what component to file against.

Comment 7 Bill Nottingham 2006-10-02 17:43:10 UTC

1) drivers are loaded and initialized in parallel. So what happens is that your
eth1 is loaded as eth0 and vice versa. Your eth1 is then renamed to __tmpXXXXXXX
so that eth0 can be named properly. Without a config file, __tmpXXXXX isn't
renamed to eth1.

2) kudzu on initial device add should write the config file and rename it from
__tmpXXXXX. This code was just added recently, though. I suspect this code might
have issues with wireless adapters where the first configuration of the device
doesn't actually create a ethX device due to no firmware being present.

Comment 8 Bernard Johnson 2006-10-02 18:05:17 UTC

Thanks for the explanation.  I'll follow up on #2 as time permits.