Bug 114149 - doesn't find new eth1 device unless noted in modules.conf
Summary: doesn't find new eth1 device unless noted in modules.conf
Alias: None
Product: Fedora
Classification: Fedora
Component: kudzu   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-23 08:48 UTC by Moritz Barsnick
Modified: 2014-03-17 02:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-10 15:58:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from "lsusb -v" (23.15 KB, text/plain)
2005-09-26 08:07 UTC, Moritz Barsnick
no flags Details

Description Moritz Barsnick 2004-01-23 08:48:59 UTC
Description of problem:
kudzu doesn't recognize a new USB ADSL modem which installs itself as 
ethx, unless its driver is noted in modules.conf.

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

How reproducible:
always (?)

Steps to Reproduce:
1. Install a new modem and driver which creates an ethernet device
2. Run system-config-network
3. Try to create a new xDSL connection.
Actual results:
See only the previously known Ethernet devices.

Expected results:
See the new device as well.

Additional info:
I'm using the German eagle-usb driver for the Allied Telesyn AT-AR215 
(Analog Devices chipset) ADSL modem, available from
http://eagle-usb.eisfront.de/ .
When this driver is loaded by hotplug, and the modem is correctly 
initialized, a new device pops up under "ifconfig -a". I used to have 
only eth0 (onboard Ethernet device), now there's also eth1 with the 
correct MAC address.
Nevertheless, kudzu doesn't detect a new device, therefore 
system-config-network doesn't allow me to use it for a new connection 
I found a "workaround" by coincidence ("find /etc -type f | xargs 
grep eth" ;->): If I add "alias eth1 eagle-usb" in modules.conf, 
kudzu recognizes the device. (I need to fix the driver to eth1 now, 
though.) Nevertheless, the driver works fine manually 
(pppd/rp-pppoe/route) without this entry.
Is this perhaps necessary for kudzu/whatever to "query" eth1 in the 
kernel? I realize that kudzu needs to know what is there, but I 
really missed an instruction for this, because the actual driver 
worked fine.
-> Documentation update?
-> Detection algorith update (also query /proc/bus/usb/)?


Comment 1 Bill Nottingham 2005-04-28 18:50:18 UTC
Does this persist in FC3 and later releases?

Comment 2 Moritz Barsnick 2005-05-26 07:58:53 UTC
Sorry for the late answer - I needed to get around to setting up a new 
installation to check for this (still running FC2 on the initial machine).

Yes, I still see this in FC3 + current updates. It's still exactly as described 
in the original report. The interface eth1 is up, but s-c-n doesn't let me 
configure it.

Comment 3 Bill Nottingham 2005-09-23 20:54:50 UTC
Can you attach the output of 'lsusb -v'?

Comment 4 Moritz Barsnick 2005-09-26 08:07:27 UTC
Created attachment 119247 [details]
Output from "lsusb -v"

This is from the machine from the original bug report. I assume you need the
info about the ADSL modem, and the rest may be irrelevant (like my old *cough*
kernel). I could provide output from the newly set up machine if it's of any
more value, but you'd need to give me a few days. ;-)

Comment 6 Bill Nottingham 2007-09-18 19:15:03 UTC
Apologies about the delay. We don't have this hardware in house. Does this
persist on F7 or similar?  kudzu and system-config-network have changed
dramatically since then.

Comment 7 petrosyan 2008-03-10 15:58:01 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

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