When eth0 is unmanaged, system connections for other NICs aren't displayed nor used

Bug #391040 reported by Alkis Georgopoulos
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: network-manager

If eth0 is assigned a static IP in /etc/network/interfaces,
then NM doesn't display nor use any system-connections defined for *other* NICs.

I include the output from trying to add a new connection:
1. I run nm-connection-editor.

2. I press the Add button, fill some static IP info, ***check the [v] Available to all users*** checkbox, and click Apply.
(the "Invalid setting IPv4 Settings" message is displayed while filling the dns server)

3. The result is that without getting any error message on the GUI, the connection is not displayed at all. So one would think that it was discarded; however, if I look at the file system, it's there, but it's like NM doesn't read it at all. See the output of "sudo ls -lha /etc/NetworkManager/system-connections/" below:

Follows the terminal output of the above steps:
teacher@server:~$ nm-connection-editor

(nm-connection-editor:3597): GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed

** (nm-connection-editor:3597): WARNING **: nm_connection_list_new: failed to load VPN plugins: Couldn't read VPN .name files directory /etc/NetworkManager/VPN.

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings: addresses

** (nm-connection-editor:3597): WARNING **: ui_to_setting: IPv4 address '<none>' missing or invalid!

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: ui_to_setting: IPv4 prefix '<none>' missing!

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

** (nm-connection-editor:3597): WARNING **: Invalid setting IPv4 Settings

teacher@server:~$ sudo ls -lha /etc/NetworkManager/system-connections/
total 12K
drwxr-xr-x 2 root root 4.0K 2009-06-23 12:32 .
drwxr-xr-x 4 root root 4.0K 2009-06-21 18:26 ..
-rw------- 1 root root 337 2009-06-23 12:32 Wired connection 1

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1)
Package: network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
Uname: Linux 2.6.28-13-generic i686
WpaSupplicantLog:

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Some extra information:

If I don't check the "[ ] Available to all users" checkbox, then the connection is created / displayed just fine.

But if, later on, I re-open nm-connection-editor and check the "[v] Available to all users" checkbox, the connection is hidden (=unusable) again. I can see that the proper /etc/NetworkManager/system-connections/<file> was created for the connection; but it doesn't show up neither in nm-connections-editor nor in the network manager applet.

Also, it doesn't matter if the unmanaged connection is a wired or a wireless one; as long as one interface has a static IP in /etc/network/interfaces, all NM _system_ connections for the other interfaces are hidden/unusable.

Revision history for this message
Alexander Sack (asac) wrote :

i havent reproduced this myself, but after discussion on IRC i want to take a look. assigning.

Changed in network-manager (Ubuntu):
assignee: nobody → Alexander Sack (asac)
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

I tried putting https://edge.launchpad.net/~network-manager/+archive/trunk to my sources, but that didn't solve the problem.

Moreover, there was a second problem with the PPA nm version: the "[ ] Available to all users" checkbox was disabled (grayed out) and I couldn't even try to create a new system connection.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 391040] Re: When eth0 is unmanaged, system connections for other NICs aren't displayed nor used

On Tue, Aug 04, 2009 at 07:53:18AM -0000, Alkis Georgopoulos wrote:
> I tried putting https://edge.launchpad.net/~network-
> manager/+archive/trunk to my sources, but that didn't solve the problem.
>
> Moreover, there was a second problem with the PPA nm version: the "[ ]
> Available to all users" checkbox was disabled (grayed out) and I
> couldn't even try to create a new system connection.
>

Yeah, I think the system settings plugins are not enabled anymore atm.
We should put the --config=/etc/NetworkManager/nm-system-settings.conf
in the /etc/default/NetworkManager or something.

 - Alexander

Revision history for this message
Andreas Chatziagapiou (xagapiou) wrote :

I found in the ubuntu forums that by editing the nm-system-settings.conf:
sudo nano /etc/NetworkManager/nm-system-settings.conf

and changing the managed to true:
managed=true

and then by reseting the network manager settings:
sudo killall nm-system-settings

i can see all of my pre-added connections and i can successfully connect to the net. But when the system restarts i have to "sudo killall nm-system-settings" again.

Revision history for this message
David Girault (dfgweb) wrote :

Same here,

after editing /etc/NetworkManager/nm-system-settings.conf to set managed to true in the [ifupdown] section,

and restart the network-manager service, the saved system connection for eth1 was now used. It is also shown in the nm-applet.

Without this change, none of system connections was shown in nm-applet.

Hope this will be resolved, because I don't want that my ifupdown configured interfaces was managed by NetworkManager.

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

The problem and the "managed=true" workaround still exist in Lucid.

Martin Pitt (pitti)
Changed in network-manager (Ubuntu):
assignee: Alexander Sack (asac) → nobody
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

AFAIK this is expected behavior: interfaces managed outside NetworkManager (e.g. in /etc/network/interfaces) are ignored and considered up (but nothing else is done); unless the value of the key "managed" (under [ifupdown]) is set to true in /etc/NetworkManager/NetworkManager.conf. Its value defaults to false.

Now whether that works well with dnsmasq is an entirely different matter, but if there are issues with that it should be filed as a separate bug.

Since it's "fixed" in all supported Ubuntu releases (this behavior predates dnsmasq being enabled by NM), I'm closing this a Fix Released.

Changed in network-manager (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Mathieu I think you misunderstood the issue.

In 10.04, if I had this in my /etc/network/interfaces:
> auto lo
> iface lo inet loopback
> auto eth0
> iface eth0 inet dhcp

then network-manager didn't show system connections for *eth1*. Not eth0, eth1.

In other words, it was impossible to manage eth0 with /etc/network/interfaces and eth1 with network-manager.

But I just tested in 12.04 and it appears to have been fixed (the test case I just mentioned works fine without editing any nm configuration files at all), so I'm leaving it fix-released.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.