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): 0.3.1-1 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.
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 disconnected.
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)
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
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 link-checking). Thanks! Dan
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 wireless. 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.
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 04) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) 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)
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp