Bug 1054671

Following the advice from this forum thread (http://forums.fedoraforum.org/showthread.php?t=295988), I enabled the "network" service with chkconfig.

The interface is now up upon boot, but networkManager still shows the network as disconnected, doesn't show the interface in the gnome network settings dialog, and so applications such as Firefox start in offline mode.

Something I failed to mention: I still need to run "sudo dhclient ens33" manually to get network access.

Hi Joël,

I stumbled onto this researching an unrelated issue, and just have a few comments:

An interface can be managed by NetworkManager, or the network service, not both. Simply enabling the network service with `chkconfig` should have no discernable impact unless you have explicitly declared "NM_CONTROLLED=no" in /etc/sysconfig/network-scripts/ifcfg-whatever . If ifcfg-ens33 declares "ONBOOT=no", the network service will also not bring up the interface at boot.

ifcfg-ens33, nm-cli, nm-connection-editor, and the GNOME settings network panel each offer a way to set the interface to be on at boot.  You haven't indicated if you have attempted to check or verify this setting.

Some additional info:

The network interface does not show at all in the Gnome network settings (regardless of the status of the "network" service.

nm-connection-editor shows the interface and everything seems normal. NM is set to bring it up automatically and all users are allowed to use it.

I've been able to bring up the interface manually with nmcli. However now I've added "NM_CONTROLLED="no"" in ifcfg-ens33 and it doesn't work anymore (says Error: Connection activation failed: Device not managed by NetworkManager or unavailable, I guess that makes sense).

Now that I've added "NM_CONTROLLED="no"" to ifcfg-ens33, dhcp is done automatically which is a plus. However applications such as firefox or thunderbird seem not to be aware of the interface, so they start in offline mode. My guess is that they rely on network manager to get the state of the connection.

NM_CONTROLLED=no says NetworkManager not to touch/manage the interface.
In most case you don't need this. NetworkManager and legacy network.service should cooperate quite well. Actually, if NM runs ifup/ifdown passes the requests to nmcli.

Can you get the following data for us to look at:
$ nmcli con show active
$ nmcli device
$ ip link
$ ip addr
NM logs (journalctl -u NetworkManager)

As for the interface name, now systemd-udevd make interface renames at early boot, search for "renamed network interface <old-name> to <new-name>" in the journal.

Would you first update to newest NM package for F20?

Created attachment 876038 [details]
NetworkManager logs

journalctl -u NetworkManager -b > nm.log

Here are the requested outputs.

[joel@fedora-joel ~]$ nmcli con show active
NAME  UUID  DEVICES  DEFAULT  VPN  MASTER-PATH 

[joel@fedora-joel ~]$ nmcli device
DEVICE  TYPE      STATE     
ens33   ethernet  unmanaged 
lo      loopback  unmanaged 

[joel@fedora-joel ~]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:0c:29:fa:e9:7d brd ff:ff:ff:ff:ff:ff

I can run the same after removing NM_CONTROLLED="no" if you think that's useful.

Joël, you can't demonstrate NetworkManager's handling of the connection if you have configured the system so that NetworkManager ignores that connection.  You've demonstrated that NetworkManager does not control your connection if you set NM_CONTROLLED="no", which is expected and not a bug.  The log files and output you share should reflect the system's state while you are experiencing the bug, so yes, it would be useful to show logs and output after commenting out NM_CONTROLLED=no.

Sorry, I had forgotten about this bug. It's been fixed for a while, but I don't know what fixed it.