Bug 137341 - Network Manager dies after disconnecting from wired network second time
Network Manager dies after disconnecting from wired network second time
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Depends On:
  Show dependency treegraph
Reported: 2004-10-27 13:06 EDT by Brian G. Anderson
Modified: 2008-05-06 20:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 20:02:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log of NM activity (20.13 KB, text/plain)
2004-10-27 13:17 EDT, Brian G. Anderson
no flags Details
Log file (49.95 KB, text/plain)
2005-02-08 16:54 EST, Brian G. Anderson
no flags Details

  None (edit)
Description Brian G. Anderson 2004-10-27 13:06:33 EDT
Description of problem:
If I boot my laptop with both a wireless and wired interface, NM
correctly selects the wired one (eth0).  If I disconnect eth0 it
correctly switches over to wirelss (eth1) which was previously set up
with the proper ESSID and WEP key.  If I reconnect eth0 it switches
over to it.  Now I disconnect again: it switches to eth1, but NM dies
with no message and the panel icon disappears.

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

How reproducible:
Every time

Steps to Reproduce:
1. Boot system with eth0 connected
2. Disconnect eth0
3. Connect eth0
4. Disconnect eth0 (NM dies and panel icon disappears)
Actual results:
NM dies

Expected results:
NM lives

Additional info:
The wireless interface is connected by NM, but then it disappears
without a trace.  There is nothing obvious in the log which I will attach.

I can restart NM, but the panel icon doesn't return and NM doesn't
seem to work right because subsequent disconnects are not recognized
and eth0 is not activated.

This is a Dell Lattitude C840 with an internal PCMCIA Prism/Instersil
card using orinoco drivers.
Comment 1 Brian G. Anderson 2004-10-27 13:17:20 EDT
Created attachment 105848 [details]
log of NM activity

I've include my log from the boot of NM until it got into a failed state. 
About midway you'll see that I had to restart NM.  Just before that NM had died
with no message.  Even after restart, it fails to bring eth1 up when eth0 is
Comment 2 Dan Williams 2005-01-29 16:50:54 EST
Hmm, orinoco drivers have some problems (no scanning support for
in-kernel drivers), but does a newer version of NetworkManager work
better for you?  (there are newer versions in FC3-updates)
Comment 3 Brian G. Anderson 2005-02-02 12:03:18 EST
I've upgraded to the latest NM, and NMinfo still is acting funny

1. Even though I start NM as a service, it doesn't start eth0 when I
boot up.  When I start NMInfo it doesn't appear in the panel.  When I
restart NM then NMInfo appears and eth0 is connected.

2.  If I unplug eth1 then my CPU usage and load skyrocket making the
sytem unusable for about a minute.  Then NMInfo goes into what appears
to be a scanning mode.  The log mentions it trying to start eth1, but
it appears to ignore the essid and key settings I configured eth1 for
and as a result never connects.

3.  So then I try to use NMInfo to create another wireless network. 
This works and then my wireless connection works.  However, NMInfo
never remembers the connection, and I have to create it every time. Is
there some way to make it remember a connection?  Why isn't it using
the configured information from eth1?

4.  When I connect eth0 NM switches over to eth0.  However, when I
disonnect it, it doesn't always find eth1 again.

It's too bad because I would really like NM to work, but I'm
Comment 4 Dan Williams 2005-02-02 12:15:54 EST
Can you post output from /var/log/messages for this entire session, or
just email it to me directly? (dcbw at redhat dot com).

I also assume that eth1 is wireless, and eth0 is wired, and that
you're using DHCP on both interfaces.

NM is designed to ignore the configured information in the ifcfg-eth*
files created by system-config-networking.  NM is a lot more dynamic
than those tools allow.  When you first use NM, you need to pull the
menu down and select your wireless network.  From that point on, NM
will remember that network and that network's WEP key, and
automatically connect to it when you start the laptop up in that
location the next time.  So in this way it does remember your
settings, but it doesn't take them from the ifcfg-eth* file.

If you post the output of /var/log/messages, that should help figure
otu what's going on with your interfaces.  Also, could you post the
output of 'lspci', as there are some network cards that NetworkManager
doesn't work extremely well with due to driver bugs (ie wireless
drivers that dont' support scanning, and wired drivers that don't do

Comment 5 Brian G. Anderson 2005-02-08 16:52:24 EST
First of all thank you for taking the time to help me.

You are correct in your reply above, that eth0 is wired and eth1 is

So I attached my log file as well as the output of lspci and cartcdtl
ident since I have a Dell Lattitude with a TrueMobile card that
appears as a PC-card device.  My transcript of events follows:

I reboot the machine and notice that at 5:39.22 NM starts but never
sees eth0 and doesn't seem to have eth1 setup correctly either. NMInfo
isn't showing anything on my panel. 

At 5:41 I restarted NM (service NetworkManager restart) and it sees
eth0 fine.  NMInfo appears showing the rj-45 plug icon.  I notice that
it is continually chatting in the log about eth0 going in and out of
range, but I'm not sure why since I'm not using eth1.

At 5:46 I pull the eth0 plug.  The NMInfo shows the 'two dots with a
spinning circle' icon.  NM seems sees that it should try eth1, and it
correctly notices that CLOUDIO is the network it should use.  I'm not
exactly sure how it found CLOUDIO since in previous sessions I had
created/opened CLOUDIO as a wireless network.  Perhaps it scanned it,
but I thought the truemobile didn't support scanning. However, it is
trying to connect to CLOUDIO unencrpypted, even though I created it as
an encrypted network.  NMInfo doesn't show CLOUDIO at all in its list
of wireless networks (in fact 'wireless networks' is greyed out) so I
can't check the setting for COUDIO, if NMInfo even has one.

As I mentioned, I have previously tried to create CLOUDIO using
NMInfo, and the first time I create it, NM connects to it.  But on
subsequent reboots it disappears from the NM panel.  I'm not sure if
this is relevant though.

Thanks for any insight.
Comment 6 Brian G. Anderson 2005-02-08 16:54:09 EST
Created attachment 110834 [details]
Log file

The output of lspci and cardctl are:

00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev

00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 Mobile PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio
Controller (rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 Go]
(rev a3)
02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)

02:01.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller
02:01.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller
02:01.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394 Controller
02:03.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller
(rev 01)

Socket 0:
  no product info available
Socket 1:
  no product info available
Socket 2:
  product info: "Dell", "TrueMobile 1150 Series PC Card", "Version 01.01", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)
Comment 7 Bug Zapper 2008-04-03 11:43:42 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 8 Bug Zapper 2008-05-06 20:02:23 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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