After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733890 - Create bridge connections (master and slave) by hand behind NM's back; do 'ifup slave'; master connection not found
Create bridge connections (master and slave) by hand behind NM's back; do 'if...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-07-28 22:54 UTC by Adam Williamson
Modified: 2020-11-12 14:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Williamson 2014-07-28 22:54:52 UTC
Hah, so this is another corner case I found in bridge testing. In https://bugzilla.gnome.org/show_bug.cgi?id=733641 I wrote:

"Say you have a bridge device 'br0' and a slaved interface 'eth0'. If you try
and bring up the slaved interface first:

# ifup eth0

you'll get:

Error: Connection activation failed: Master connection not found or invalid

so obviously you have to bring up the bridge device first."

But that wasn't actually entirely true. In fact, NetworkManager usually does a good thing in this case: 'ifup slave' brings up both slave and bridge, and everything works, and everyone's happy.

The "Master connection not found or invalid" failure is actually a corner case I just happened to hit on the path I was testing. I'm pretty sure I've isolated how it happens. Here's how to reproduce:

1. Delete /etc/sysconfig/network-scripts/ifcfg-* and delete all NetworkManager profiles listed in 'nmcli con show', so you have a completely blank slate

2. Hand-edit /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/sysconfig/network-scripts/ifcfg-br0 defining a simple, correct bridged connection

3. Run 'nmcli con show', see that still no connections are listed

4. Run 'ifup eth0', observe the error occur

5. Run 'nmcli con show', see that a connection has been created for eth0 *but not for br0*

The problem is that NetworkManager isn't quite clever enough to handle this case. It *does* try and handle it. If you just create a simple single connection behind its back - say, create /etc/sysconfig/network-scripts/ifcfg-eth0 , defining a simple DHCP connection, and immediately run 'ifcfg-eth0' - some smarts somewhere in NetworkManager realize it should check if an ifcfg-eth0 file has appeared and create a new NetworkManager connection based on it if it exists. That simple single connection case works.

But the smarts aren't smart enough to handle a bridge. At step 5 above, you can see that NM is smart enough to create a connection for the slave, but it's not smart enough to go the extra mile and check if an ifcfg-br0 (or whatever) has appeared, and if so, create a connection for that too. So src/nm-manager.c 's find_master() function gets called still without, so far as NetworkManager is concerned, the 'br0' connection really existing at all, and that function (correctly, in a sense) bails with the "Master connection not found or invalid" error.

Suggestion: whatever bit of NM does the 'check if an ifcfg file matching the connection on which ifup was called has appeared, and create a connection if so' should be extended to check if the new connection is a bridge slave, and if so, also check for an ifcfg file matching the name of the bridge master and create a connection for that too, before actually trying to bring up the slave.

I listed hand-editing as a handy way to reproduce above, but the way I hit this issue at first was with virt-manager. virt-manager sets up bridged connections by simply creating the config files in /etc/sysconfig/network-scripts and then immediately starting to do 'ifup' calls, so it runs into this bug in some cases (whether it hits this bug or another one depends on exactly what connections you start with before running virt-manager, and what state they're in when you try to create and bring up the bridge in virt-manager).
Comment 1 Adam Williamson 2014-07-28 22:56:10 UTC
This bit of the report:

"say, create /etc/sysconfig/network-scripts/ifcfg-eth0 , defining a simple DHCP connection, and immediately run 'ifcfg-eth0'"

should of course read: 

"say, create /etc/sysconfig/network-scripts/ifcfg-eth0 , defining a simple DHCP connection, and immediately run 'ifup eth0'"

Sorry.
Comment 2 Dan Winship 2014-07-29 11:52:36 UTC
(In reply to comment #0)
> Suggestion: whatever bit of NM does the 'check if an ifcfg file matching the
> connection on which ifup was called has appeared, and create a connection if
> so' should be extended to check if the new connection is a bridge slave, and if
> so, also check for an ifcfg file matching the name of the bridge master and
> create a connection for that too, before actually trying to bring up the slave.

It's actually "ifup" that does that:

        nmcli con load "/etc/sysconfig/network-scripts/$CONFIG"

(That's near the end of source_config() in /etc/sysconfig/network-scripts/network-functions.)

Of course it would be weird for ifup to "nmcli con load" the bridge device config too in this case, given that it doesn't load the bridge config in the non-NM case...
Comment 3 Adam Williamson 2014-08-14 23:16:39 UTC
I don't believe the non-NM case fails in this scenario.
Comment 4 Thomas Haller 2014-08-19 12:50:48 UTC
(In reply to comment #2)
> (In reply to comment #0)
>
> Of course it would be weird for ifup to "nmcli con load" the bridge device
> config too in this case, given that it doesn't load the bridge config in the
> non-NM case...

what do you mean? I think in the non-NM case, initscripts just care about the ifcfg-* files that are present. initscripts has nothing in particular to load.


Anyway, I think it is entirely initscripts responsibility telling NM to load config files -- as it already does now.

I think initscripts should be fixed in this case... but it doesn't seem a trivial thing to do.


How about opening a Fedora bug for initscripts and closing this as NOTABUG?
Comment 5 Dan Winship 2014-08-19 14:11:50 UTC
(In reply to comment #4)
> > Of course it would be weird for ifup to "nmcli con load" the bridge device
> > config too in this case, given that it doesn't load the bridge config in the
> > non-NM case...
> 
> what do you mean? I think in the non-NM case, initscripts just care about the
> ifcfg-* files that are present. initscripts has nothing in particular to load.

When not using NM, if you use ifup to bring up a bridge port, and the bridge device does not exist, ifup will just do "brctl addbr ${BRIDGE}" and then continue bringing up the bridge port; it makes no attempt to find an ifcfg file for the bridge.

(If you do have an ifcfg file for the bridge, and you bring it up later, then ifup will belatedly apply the ifcfg config at that point.)
Comment 6 André Klapper 2020-11-12 14:31:57 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).