Description of problem: For a standard Desktop Live image (spun from current git livecd/config) NetworkManager seems to take down the wired eth0 interface which is annoying. It would be nice to fix this for F8 final. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.3.svn2983.fc8 How reproducible: every time Steps to Reproduce: 1. login to Live fedora account Actual results: 1. bubble appears saying network was disconnected Expected results: 1. eth0 to remain up for wired connection Additional info: Oct 19 04:14:04 localhost avahi-daemon[1800]: Service "linux" (/services/ssh.ser vice) successfully established. Oct 19 04:14:05 localhost NetworkManager: <info> starting... Oct 19 04:14:05 localhost NetworkManager: <info> eth0: Device is fully-supporte d using driver '8139too'. Oct 19 04:14:05 localhost NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. Oct 19 04:14:05 localhost NetworkManager: <info> Bringing up device eth0 Oct 19 04:14:05 localhost kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 Oct 19 04:14:05 localhost NetworkManager: <info> Deactivating device eth0.
I think the "disconnected" bubble dialog is a confusing too since eth0 was not up.
Same thing here with fresh install from 10/24. Network manager shuts down the network (eth1 here): Oct 24 14:32:21 cynosure NetworkManager: <info> starting... Oct 24 14:32:21 cynosure NetworkManager: <info> eth1: Device is fully-supported using driver '3c59x'. Oct 24 14:32:21 cynosure NetworkManager: <info> (eth1): exporting device as /org/freedesktop/NetworkManager/Device/3 Oct 24 14:32:21 cynosure NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth1'. Oct 24 14:32:21 cynosure NetworkManager: <info> Bringing down device eth1 Oct 24 14:32:21 cynosure avahi-daemon[2214]: Interface eth1.IPv4 no longer relevant for mDNS. Oct 24 14:32:21 cynosure avahi-daemon[2214]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 24 14:32:21 cynosure dhclient: receive_packet failed on eth1: Network is down Oct 24 14:32:21 cynosure avahi-daemon[2214]: Withdrawing address record for fe80::2b0:d0ff:fe0d:f2a3 on eth1. Oct 24 14:32:21 cynosure avahi-daemon[2214]: Withdrawing address record for 192.168.0.72 on eth1. Oct 24 14:32:23 cynosure NetworkManager: <info> Bringing up device eth1 Oct 24 14:32:23 cynosure kernel: eth1: setting full-duplex. Oct 24 14:32:23 cynosure avahi-daemon[2214]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 24 14:32:23 cynosure avahi-daemon[2214]: New relevant interface eth1.IPv4 for mDNS. Oct 24 14:32:23 cynosure avahi-daemon[2214]: Registering new address record for 192.168.0.72 on eth1.IPv4. Oct 24 14:32:23 cynosure NetworkManager: <info> Deactivating device eth1. Oct 24 14:32:23 cynosure avahi-daemon[2214]: Withdrawing address record for 192.168.0.72 on eth1. Oct 24 14:32:23 cynosure avahi-daemon[2214]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 24 14:32:23 cynosure avahi-daemon[2214]: Interface eth1.IPv4 no longer relevant for mDNS. Oct 24 14:32:23 cynosure NetworkManager: <info> eth0: Device is fully-supported using driver '3c59x'. Oct 24 14:32:23 cynosure NetworkManager: <info> (eth0): exporting device as /org/freedesktop/NetworkManager/Device/2 Oct 24 14:32:23 cynosure NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. Oct 24 14:32:23 cynosure NetworkManager: <info> Bringing up device eth0 Oct 24 14:32:23 cynosure kernel: eth0: setting half-duplex. Oct 24 14:32:23 cynosure kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 24 14:32:23 cynosure NetworkManager: <info> Deactivating device eth0. Oct 24 14:32:27 cynosure NetworkManager: <info> Trying to start the supplicant... Oct 24 14:32:27 cynosure NetworkManager: <info> (eth1) supplicant interface is now in state 1 (from 0). Oct 24 14:32:27 cynosure NetworkManager: <info> (eth0) supplicant interface is now in state 1 (from 0). Oct 24 14:32:27 cynosure NetworkManager: <info> (eth1) supplicant interface is now in state 2 (from 1). Oct 24 14:32:27 cynosure NetworkManager: <info> (eth0) supplicant interface is now in state 2 (from 1).
should be fixed in svn3030
please test when it hits, thanks!
*** Bug 333121 has been marked as a duplicate of this bug. ***
Created attachment 240741 [details] NM output in nodaemon mode I am using a wireless connection [ath0] for out- and ingoing connectivity and a wired device [eth0] to attach my JetDirect interfaced HP LaserJet 4000N printer to my system. Version 0.7.0-0.5.svn3030.fc8 still knocks out my wired network connection or doesn't bring it up which means that I have to activate eth0 by hand and restart the CUPS daemon in order to be able to access my printer. After that, ath0 and eth0 live peacefully side by side.
Created attachment 240751 [details] NM output in nodaemon mode while interface eth0 active Same as previous attachment but now launching NM while interface eth0 is active.
Can you try checking the 'autoconnect' checkbox in GConf for the ethernet connection? Run 'gconf-editor' and then drill down to /system/networking/connections, find the "Auto Ethernet" connection (name is in the 'connection' directory) and check the autoconnect option. See if that works for you. If you installed before and including Test 3, autoconnect functionality wasn't available at that point.
(In reply to comment #8) First of all, under /system/networking/connections, only the WLAN connection shows up and this with 2 entries, namely "1" and "2". The "autoconnect" box is checkmarked in both cases, but again, this only applies to the wireless connection for which this feature seems to work correctly since I am prompted to enter the password every time I log in.
(In reply to comment #4) > please test when it hits, thanks! I tested a live spin of current rawhide and the issue looks fixed to me now. Thanks!
I still don't see it bringing up eth1 for me: Oct 30 09:34:46 cynosure NetworkManager: <info> starting... Oct 30 09:34:46 cynosure NetworkManager: <info> eth1: Device is fully-supported using driver '3c59x'. Oct 30 09:34:46 cynosure NetworkManager: <info> (eth1): exporting device as /org/freedesktop/NetworkManager/Device/3 Oct 30 09:34:46 cynosure NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth1'. Oct 30 09:34:46 cynosure NetworkManager: <info> Bringing down device eth1 Oct 30 09:34:46 cynosure avahi-daemon[2116]: Interface eth1.IPv4 no longer relevant for mDNS. Oct 30 09:34:46 cynosure avahi-daemon[2116]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 30 09:34:46 cynosure dhclient: receive_packet failed on eth1: Network is down Oct 30 09:34:46 cynosure avahi-daemon[2116]: Withdrawing address record for fe80::2b0:d0ff:fe0d:f2a3 on eth1. Oct 30 09:34:46 cynosure avahi-daemon[2116]: Withdrawing address record for 192.168.0.72 on eth1. Oct 30 09:34:49 cynosure NetworkManager: <info> Bringing up device eth1 Oct 30 09:34:49 cynosure kernel: eth1: setting full-duplex. Oct 30 09:34:49 cynosure avahi-daemon[2116]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 30 09:34:49 cynosure avahi-daemon[2116]: New relevant interface eth1.IPv4 for mDNS. Oct 30 09:34:49 cynosure avahi-daemon[2116]: Registering new address record for 192.168.0.72 on eth1.IPv4. Oct 30 09:34:49 cynosure NetworkManager: <info> Deactivating device eth1. Oct 30 09:34:49 cynosure avahi-daemon[2116]: Withdrawing address record for 192.168.0.72 on eth1. Oct 30 09:34:49 cynosure avahi-daemon[2116]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.72. Oct 30 09:34:49 cynosure avahi-daemon[2116]: Interface eth1.IPv4 no longer relevant for mDNS. Oct 30 09:34:49 cynosure NetworkManager: <info> eth0: Device is fully-supported using driver '3c59x'. Oct 30 09:34:49 cynosure NetworkManager: <info> (eth0): exporting device as /org/freedesktop/NetworkManager/Device/2 Oct 30 09:34:49 cynosure NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. Oct 30 09:34:49 cynosure NetworkManager: <info> Bringing up device eth0 Oct 30 09:34:49 cynosure kernel: eth0: setting half-duplex. Oct 30 09:34:49 cynosure kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 30 09:34:49 cynosure NetworkManager: <info> Deactivating device eth0. Oct 30 09:34:52 cynosure NetworkManager: <info> Trying to start the supplicant... Oct 30 09:34:53 cynosure NetworkManager: <info> (eth1) supplicant interface is now in state 1 (from 0). Oct 30 09:34:53 cynosure NetworkManager: <info> (eth0) supplicant interface is now in state 1 (from 0). Oct 30 09:34:53 cynosure NetworkManager: <info> (eth1) supplicant interface is now in state 2 (from 1). Oct 30 09:34:53 cynosure NetworkManager: <info> (eth0) supplicant interface is now in state 2 (from 1). gconf-editor only shows connections 1 and 2, 1 appears to be wired with autoconnect, 2 appears to be wireless with autoconnect. (Not that I should have to do anything with gconf-editor to get this to work out of the box). NetworkManager-0.7.0-0.5.svn3030.fc8
Orion, whats the output of /usr/bin/nm-tool for your eth0? NM won't autoconnect if the driver/card don't support carrier detect, which some still don't, like the ne2000 emulator in qemu for example. Short answer to that is that stuff won't Just Work unless the hardware & drivers Just Work too, if this is your problem. There should be a section like this: Capabilities: Supported: yes Carrier Detect: yes Speed: 100 Mb/s If you don't see Carrier Detect == yes, that's likely your problem. What's the lspci or lsusb output for your card? I've got a 3c59x-driven box here and it supports carrier detect (3Com 3c905C-TX/TX-m [Tornado])
$ nm-tool NetworkManager Tool State: connected - Device: eth1 ---------------------------------------------------------------- Type: Wired Driver: 3c59x Active: yes HW Address: 00:B0:D0:0D:F2:A3 Capabilities: Supported: yes Carrier Detect: yes Speed: 100 Mb/s It's worked for me in the past, it just doesn't now. I wonder if there is some disconnect between the network configs in gconf and NM. I go in and out of a docking station (so eth1 comes and goes) and have a pcmcia wireless card (so wlan0 comes and goes) - though you would think NM would be designed for this.
Just did a fresh install and different laptop (still a 3c59x device though), and the network isn't coming up automatically: Nov 7 11:53:30 localhost NetworkManager: <info> starting... Nov 7 11:53:30 localhost NetworkManager: <info> eth0: Device is fully-supported using driver '3c59x'. Nov 7 11:53:30 localhost NetworkManager: <info> (eth0): exporting device as /org/freedesktop/NetworkManager/Device/2 Nov 7 11:53:30 localhost NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. Nov 7 11:53:30 localhost NetworkManager: <info> Bringing up device eth0 Nov 7 11:53:30 localhost kernel: eth0: setting full-duplex. Nov 7 11:53:30 localhost NetworkManager: <info> Deactivating device eth0. Nov 7 11:53:36 localhost NetworkManager: <info> Trying to start the supplicant... Nov 7 11:53:36 localhost NetworkManager: <info> (eth0) supplicant interface is now in state 1 (from 0). Nov 7 11:53:36 localhost NetworkManager: <info> (eth0) supplicant interface is now in state 2 (from 1). NetworkManager-0.7.0-0.5.svn3030.fc8
orion, you may need to select the wired item from the menu just once and after that it will autoconnect. This could be an issue if you upgraded through to F8 final.
I contend that this should happen automatically with having to do *any* user interaction, as the title of this bug implies. I cannot make use of NM at our office until this is the case. Is there any technical reason preventing this from being the case? This is a fresh install of F8.
Is nm-applet running on login? Can you give me the output of: gconftool-2 --dump /system/networking/connections
I haven't logged in yet. # gconftool-2 --dump /system/networking/connections <gconfentryfile> <entrylist base="/system/networking/connections"> </entrylist> </gconfentryfile>
If you log in once this will work. Even when the system config daemon lands, there won't be any automatic connections set up for you unless you: 1) have configured them in the Anaconda install screens, or 2) have administrator privileges and have a) logged in at least once, and b) pushed a connection that you have created after logging in once to the system settings daemon, or 3) Created a system settings connection through system-config-network or via ifcfg files or otherwise NM is not going to just bring stuff up because it thinks it's fun to do so. You have to tell it to do so, or log in. The ifup/ifdown architecture doesn't bring up devices automatically either, unless explicitly told to do so via ifcfg files.
kickstart: network --device eth0 --bootproto dhcp ifcfg-eth0 is created and network comes up at boot. When NM starts it stops all networks. Now I can't remotely configure my company's newly installed laptop. This currently works with F7 (it brings eth0 up). When I log in, nm-applet is run and the machine connects to the network. But I haven't actually *configured* anything or clicked on anything other than launch nm-applet (which the session did for me automatically). NM brought stuff up because it thought it should (or it was fun to do so?) - and it was the *right* decision. What prevents this being done before nm-applet is run, when NM daemon starts up?
because the _applet_ is the policy mechanism, and the _applet_ decides what connections NM is allowed to use. NM doesn't have any connections to try before the applet gets loaded. In the quite near future there will be a system settings service which will provide administrator-defined connections (taken from ifcfg-* and other sources) before login, which will likely fix your problem.
Maybe what's needed is to have an alert that says Networks are available, but that the computer isn't connected to any of them and a quick suggestions on how to select from the available networks.