Bug 339201 - NetworkManager should bring up wired network by default if available
NetworkManager should bring up wired network by default if available
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 333121 (view as bug list)
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-10-19 01:00 EDT by Jens Petersen
Modified: 2007-11-30 17:12 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-09 15:01:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
NM output in nodaemon mode (5.43 KB, text/plain)
2007-10-27 17:34 EDT, Joachim Frieben
no flags Details
NM output in nodaemon mode while interface eth0 active (5.48 KB, text/plain)
2007-10-27 17:42 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Jens Petersen 2007-10-19 01:00:58 EDT
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.
Comment 1 Jens Petersen 2007-10-22 19:08:03 EDT
I think the "disconnected" bubble dialog is a confusing too
since eth0 was not up.
Comment 2 Orion Poplawski 2007-10-24 17:12:25 EDT
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).
Comment 3 Dan Williams 2007-10-26 23:13:12 EDT
should be fixed in svn3030
Comment 4 Dan Williams 2007-10-26 23:13:52 EDT
please test when it hits, thanks!
Comment 5 Dan Williams 2007-10-26 23:15:44 EDT
*** Bug 333121 has been marked as a duplicate of this bug. ***
Comment 6 Joachim Frieben 2007-10-27 17:34:55 EDT
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.
Comment 7 Joachim Frieben 2007-10-27 17:42:57 EDT
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.
Comment 8 Dan Williams 2007-10-27 22:29:58 EDT
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.
Comment 9 Joachim Frieben 2007-10-28 05:28:58 EDT
(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.
Comment 10 Jens Petersen 2007-10-29 04:10:32 EDT
(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!
Comment 11 Orion Poplawski 2007-10-30 11:48:08 EDT
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
Comment 12 Dan Williams 2007-10-30 15:32:19 EDT
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])
Comment 13 Orion Poplawski 2007-10-30 15:43:39 EDT
$ 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.
Comment 14 Orion Poplawski 2007-11-07 15:09:08 EST
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
Comment 15 Dan Williams 2007-11-08 09:56:16 EST
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.
Comment 16 Orion Poplawski 2007-11-08 10:56:38 EST
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.
Comment 17 Dan Williams 2007-11-08 14:59:28 EST
Is nm-applet running on login?  Can you give me the output of:

gconftool-2 --dump /system/networking/connections

Comment 18 Orion Poplawski 2007-11-08 15:08:13 EST
I haven't logged in yet.

# gconftool-2 --dump /system/networking/connections
<gconfentryfile>
  <entrylist base="/system/networking/connections">
  </entrylist>
</gconfentryfile>
Comment 19 Dan Williams 2007-11-09 15:01:53 EST
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.
Comment 20 Orion Poplawski 2007-11-09 17:01:49 EST
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?
Comment 21 Dan Williams 2007-11-13 10:57:38 EST
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.
Comment 22 Rodd Clarkson 2007-11-13 17:58:35 EST
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.

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