Bug 108178 - Maps two network devices to the same unit name
Maps two network devices to the same unit name
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2003-10-28 07:30 EST by Jan Moren
Modified: 2014-03-16 22:39 EDT (History)
3 users (show)

See Also:
Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-23 16:12:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
my dmesg when both are compiled as modules (13.32 KB, text/html)
2004-02-19 01:05 EST, Godmar Back
no flags Details

  None (edit)
Description Jan Moren 2003-10-28 07:30:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031014

Description of problem:
I have a Compal ACL10 laptop with built in Realtek 8139 ethernet and a Gemtek
Prism 2.5 wavelan PCI card (driver orinoco_pci). By default, kudzu maps both
devices to be "eth0", and only by manually editing modules.conf (adding an
"alias eth1 orinoco_pci" line) can I separate the two.

This is the output after editing the modules.conf file - not that it now thinks
it is "eth2" for some vaguely frightening reason; it is mapped to be eth1 in
modules.conf (and is working as such as I write).

# kudzu -p -c NETWORK
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: 8139too
desc: "Realtek|RTL-8139/8139C/8139C+"
network.hwaddr: 00:02:3F:B0:75:9C
vendorId: 10ec
deviceId: 8139
subVendorId: 14c0
subDeviceId: 0012
pciType: 1
pcibus:  2
pcidev:  1
pcifn:  0
class: NETWORK
bus: PCI
detached: 0
device: eth2
driver: orinoco_pci
desc: "Harris Semiconductor|Prism 2.5 Wavelan chipset"
vendorId: 1260
deviceId: 3873
subVendorId: 1260
subDeviceId: 3873
pciType: 1
pcibus:  2
pcidev:  2
pcifn:  0

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

How reproducible:

Steps to Reproduce:
It just happens by default for me.

Actual Results:  Mapped to the same device.

Expected Results:  Mapped to different devices.

Additional info:

The description says it all, really.
Comment 1 Bill Nottingham 2004-02-04 01:43:06 EST
Please try the kudzu- packages at:

These may resolve some of your issues.
Comment 2 Godmar Back 2004-02-19 01:04:16 EST
Same problem on Thinkpad T23.

Fixing /etc/modules.conf doesn't fix it if you want to use redhat-
config-network, which runs kudzu -p.

When I compile both the wired and wireless as modules, I see that the 
wireless is probed as eth0 at boot time, then the wired is probed as 
eth1, then (both are unloaded, I assume) then the wired is probed as 
eth0.  In other words, if only one module is loaded, it becomes eth0.
I'll attach the dmesg output.

Maybe that confuses kudzu?  Does it probe one device at a time?

I'm already using 1.1.36-1.
Comment 3 Godmar Back 2004-02-19 01:05:16 EST
Created attachment 97824 [details]
my dmesg when both are compiled as modules
Comment 4 Godmar Back 2004-02-19 01:10:47 EST
Also, when I compile both into the kernel (the e100 and the 
orinoco_pci, that is), kudzu will still probe both on eth0.

If I remove my /etc/sysconfig/hwconf file (and all ifcfg-* files 
in /etc/sysconfig/network-script, and everything 
in /etc/sysconfig/networking) and reboot, kudzu will say that a 
Prism2 card was removed (how the hell does it know that without a 
hwconf?  It should have no memory whatsoever).  When I say, okay, 
keep configuration it tells that me that a Prism2 card was added.  
When I say "ignore" it creates an entry for eth2 in hwconf.  

Obviously "keep configuration" and "ignore" don't do what they say 
they do.  Where, btw, does kudzu keep track of whether the user asked 
it to ignore something?  There doesn't seem to be field in hwconf.
Comment 5 Alex Kiernan 2004-04-01 02:44:40 EST
Does the patch in #119655 help? I had the same problem - since fixing
the problem I found & reported there & retesting w/ my Orinoco card,
it looks to have gone away.
Comment 6 Nico Kadel-Garcia 2004-05-05 15:40:11 EDT
I'm having a similar problem with my Sony Vaio PCG-SRX77P, but since 
both wired and wireless are built into this system, I can't simply 
remove a card to get it to work right.

There are also problems with the insistence by kudzu network setups 
of storing the MAC address in the /etc/sysconfig/network-
scripts/ifcfg-eth* files. This makes swapping out PC cards 
particularly adventuresome, since the old MAC address doesn't 
properly get flushed when you cnage devices or re-arrange which eth* 
device is which and makes it refuse to even shut down the previously 
active driver.
Comment 7 Bill Nottingham 2004-08-27 18:47:50 EDT
Please try the test rpms at:

Comment 8 Bill Nottingham 2005-09-23 16:12:19 EDT
This should be resolved as of FC4.

Note You need to log in before you can comment on or make changes to this bug.