bridge_ignore_without_connections.patch breaks NM created bridge at boot

[Mathias Kresin]

I've created a bridge with network-manager-gnome, the bridge slave physical device is eth0. After a reboot the bridge is brought up, but eth0 isn't attached.

First test-case:
Created a bridge with network-manager-gnome with the bridge slave physical device is eth0 and remove all other connections. After a reboot the bridge is brought up, but eth0 isn't attached. When I open /etc/NetworkManager/NetworkManager.conf and save it without any modification, eth0 is instantly added to my bridge. Strange!

Second test-case:
Created a bridge with network-manager-gnome with the bridge slave physical device is eth0. Disable the "autoconnect" of the default wired network. After a reboot the bridge is brought up, but eth0 isn't attached. Instead eth0 is brought up and full configured.

After compiling and testing different upstream versions, i could track the problem down to bridge_ignore_without_connections.patch. A network-manager package without this specific patch, brings my bridge up at boot and adds eth0 to the bridge in both test-cases.

I've checked the behaviour on my ubuntu 13.10 box with network-manager (0.9.8.0-0ubuntu22) and the trusty version network-manager (0.9.8.8-0ubuntu1) .

Till now i couldn't encounter any sideeffects of removing this patch with the bridge created by libvirt.

Regards
Mathias Kresin

[Mathieu Trudel-Lapierre (cyphermox)]

That patch shouldn't be breaking the bridge though, since I'd expect it to match existing configs so as to implicitly exclude only bridges created outside NM, such as for lxc, libvirt, etc. It was definitely required in our testing.

I'd love to see the syslog message for this, and if possible with NM is debug mode. Could you attach the debugging logs for NetworkManager as you bring it up? It might help identifying the issue with this patch and fixing whatever might be wrong with it.

Thanks!

[Mathias Kresin (mkresin)]

Find attached a syslog with NetworkManager in debug mode and with bridge_ignore_without_connections.patch. MAC & IPv6 Adresses are x-ed by me.

[Mathias Kresin (mkresin)]

Find attached a syslog with NetworkManager in debug mode and without bridge_ignore_without_connections.patch. MAC & IPv6 Adresses are x-ed by me.

[Mathieu Trudel-Lapierre (cyphermox)]

Thanks!

Maybe there is a config that isn't being read properly by NM at the time where the connections are getting matched?

I think this indicates where the problem is:
Jan 26 20:12:12 desktop NetworkManager[851]: <debug> [1390763532.45734] [nm-manager.c:2950] nm_manager_activate_connection(): Activation of 'bridge0 Sklave 1' requires master connection 'Brückenverbindung 1'
Jan 26 20:12:12 desktop NetworkManager[851]: <info> Connection 'bridge0 Sklave 1' auto-activation failed: (1) No compatible disconnected device found for master connection 9374baaf-ff05-4f4c-9e31-8e4a2b007d9f.

The system is looking for a disconnected device; I guess eth0 might not be seen as disconnected in NM (although it does not appear to be if I'm to believe the other lines nearby). It's also expecting eth0 to be a specfic device, which may be configured via a MAC address or via another config entry in the connection for Br?ckenverbindung 1". Is there anyway you could share as much of that connection file as possible?

[Mathias Kresin (mkresin)]

After rereading the bridge_ignore_without_connections.patch, i agree with you about a problem with connection matching.

IMHO the problem are not the lines you referred to, they are only a inherited error and aren't logged with a network-manager without the patch. But:

<debug> [1390763529.436635] [nm-manager.c:1898] add_device(): MATT: should inhibit: true

in conjunction with nm-manager.c:1947

if ( !manager_sleeping (self)
    && !nm_device_spec_match_list (device, unmanaged_specs) && !inhibit_managed) {

is resulting in a not called nm_device_set_managed. Obviously this is the cause. The unanswered question is why nm-manager.c:1895 nm_device_connection_match_config returns NULL.

The config i'm using with network-manager (0.9.8.8-0ubuntu1) and network-manager (0.9.8.8-0ubuntu1) minus bridge_ignore_without_connections.patch is exactly the same and attached.

[Mathias Kresin (mkresin)]

As usual the MAC-Address is x-ed by me. If you need the address, please contact me directly!

[Mathias Kresin (mkresin)]

Hi Mathieu,

I've done a few more tests. All tests are done in an english Ubuntu 13.10 qemu/kvm virtual machine, just to be sure that neither my host hardware nor my language settings are the problems.

As usual i've created a bridge via the network-manager-gnome applet, attached the only physical network device, enabled autoconnection and disabled "Automatically connect to this when it is available" for the "Wired connection 1" finally.

After a reboot the following could be seen:

0.9.8.0-0ubuntu22: eth0 up, bridge0 down, no device configured
0.9.8.0-0ubuntu22 minus bridge_ignore_without_connections.patch: eth0 up, bridge0 up, eth0 attached to bridge, bridge0 configured

Furthermore i've checked the behaviour with the upstream version e78c3e83d2e0b49641c9d484e0b35b3c6ff9f0db which is - according to the debain changelog - the version this patches was developed for.

e78c3e8: eth0 up, bridge0 up, eth0 attached to bridge, bridge0 configured
e78c3e8 plus bridge_ignore_without_connections.patch: eth0 up, bridge0 down, no device configured

May i do s.th. horribly wrong, but _for me_ it looks like the host bridge functionality is broken since the introduction of the patch.

As I stated in my initial post, i could not encounter any problems with additional libvirt bridges when i rollback the patch. Is it possible that the bug which this patch was written for, is fixed with the upstream commit 17338069e332bb73e4d9e7332b67b7853fbe83b7?

[Raoul Bhatia (raoul-bhatia)]

I can confirm this for

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"

and network-manager 0.9.8.8-0ubuntu7.

Reverting bridge_ignore_without_connections.patch (and recompiling) seems to solve this issue.

Kindly re-evaluate bridge_ignore_without_connections.patch and exclude or adapt it for Ubuntu trusty and upcoming releases.

Thanks,
Raoul

[MikeyB (supermathie)]

Looks like this also affects my configuration: http://askubuntu.com/q/520051/9083

[linuxball (linuxball)]

Bug confirmed for my system, too:

$ lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04

$ apt-cache policy network-manager
network-manager:
  Installed: 0.9.8.8-0ubuntu7
  Candidate: 0.9.8.8-0ubuntu7
  Version table:
 *** 0.9.8.8-0ubuntu7 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Regards,

Wolfgang

[Mathieu Trudel-Lapierre (cyphermox)]

I agree, the issue is probably fixed by upstream commit 17338069e332bb73e4d9e7332b67b7853fbe83b7; I'll try to get around to packing a few fixes to NM together to upload today.

[Raoul Bhatia (raoul-bhatia)]

I'm looking forward to that :)

[linuxball (linuxball)]

Me too. Mathieu, please leave a comment here as soon as the new NM package can be downloaded or is in proposed. I'd like to test it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 0.9.8.8-0ubuntu28

---------------
network-manager (0.9.8.8-0ubuntu28) utopic; urgency=medium

  * debian/patches/add_ofono_support.patch: Ignore calls to set_mm_enabled;
    we don't need to do any action when that happens. (LP: #1350332)
  * debian/patches/provisioning_wait_ofono_properties.patch: keep Online into
    consideration when setting the CONNECTED state for the modem device, as
    when flight mode is toggled the oFono Interfaces may be re-created and
    could still be Powered and Attached. (LP: #1350332)
  * debian/patches/ignore_rfkill_if_urfkill_present.patch: don't write state
    file on state changes from urfkill, as urfkill will handle persistence
    itself. (LP: #1381406)
  * debian/patches/bridge_ignore_without_connections.patch: Drop patch; this
    is no longer necessary given upstream commit 17338069 which avoids
    touching bridge connections that weren't created by NM. (LP: #1273201)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 09 Oct 2014 14:38:18 -0400

[MikeyB (supermathie)]

I see the fix released for 14.10, ETA for this to be backported to trusty?

[MikeyB (supermathie)]

Is there any way to mark this as affecting the 14.04 LTS? It's status fix-released, but the fix has *not* actually been released.

[John Ruiz (jar349)]

Is there any plan to get this into 14.04 LTS?

I run Mint, which is going to stay on 14.04 LTS for the next few releases, so unless it gets into 14.04 LTS, Mint users won't be able to get this fix for - potentially - a long time.

[Martin Bergner (martin-bergner)]

Again, what is the state of this bug for 14.04? It makes nm useless for my workflow of having both a VM and a VPN. Can you please backport this fix?

[Cedric Schieli (cschieli)]

+1

I've been running the backported fix (just dropped the patch) without a glitch for several month.
If that helps, I've just created a PPA for this backport (currently rebuilding): https://launchpad.net/~cschieli/+archive/ubuntu/bug1273201

[Julian Alarcon (julian-alarcon)]

Hi

I got the same problem in Ubuntu 14.04.

I used KVM on Ubuntu 14.04 with network using bridge, modifying the /etc/network/interfaces but today I tried to set the bridge using Network Manager.

After setting the bridge on network manager, I used the brctl show and the eth0 card were not linked to the bridge, but taking the advice of opening the Network Manager configuration file (/etc/NetworkManager/NetworkManager.conf) and saving it without editing it, I got the bridge up.

So this problem is still there in Ubuntu 14.04, can somebody set the affect release to Ubuntu 14.04 Trusty Tahr?

Also, when I set this bridge, I got an error in the network, my PC is connected to a Cisco Switch 2960-S, my port become err-disable status. Because of this I removed all the NM configuration and used the old method and the bridged network worked again.

[Jernej Jakob (jjakob)]

Any news on fixing the bug?
Yesterday a new version of network-manager 0.9.8.8-0ubuntu7.2 got pushed out, replacing the version from cschieli's ppa 0.9.8.8-0ubuntu7.1+athome1, causing the bridges to break once again

[Cedric Schieli (cschieli)]

+1

Updated version currently rebuilding in my PPA: https://launchpad.net/~cschieli/+archive/ubuntu/bug1273201

[Thomas Staerk (staerk)]

the PPA of Cedric is very helpful, but in my opinion it should be the intention of a LTS to publish the fixed version here, so Canonical should give 14.04 users a solution

[Alexander A. Kompaniets (bhrigu)]

Hi, Cedric!
The latest version' changelog (0.9.8.8-0ubuntu7.3 from Canonical repos) doesn't contains any relevant bugfixes,
so I think the bug is still there.

Could you please update your PPA? Thanks in advance!

[Cedric Schieli (cschieli)]

Package version 0.9.8.8-0ubuntu7.3+athome1 currently rebuilding in my PPA.

2016-02-09 9:38 GMT+01:00 Alexander A. Kompaniets <
<email address hidden>>:

> Hi, Cedric!
> The latest version' changelog (0.9.8.8-0ubuntu7.3 from Canonical repos)
> doesn't contains any relevant bugfixes,
> so I think the bug is still there.
>
> Could you please update your PPA? Thanks in advance!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1273201
>
> Title:
> bridge_ignore_without_connections.patch breaks NM created bridge at
> boot
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1273201/+subscriptions
>