Bug 1457691

Created attachment 1284018 [details]
Video record

Created attachment 1284019 [details]
Information about the host

Created attachment 1284029 [details]
Diagnostic files from PPC64

The same effect appears when testing on architecture PPC64.

Created attachment 1284030 [details]
Diagnostic files from x86_64 VM

The same effect appears on architecture x86_64 VM, but not on a physical machine. On the physical machine it is OK.

(gnome-control-center:31072): libnm-CRITICAL **: ((libnm-core/nm-connection.c:1815)): assertion '<dropped>' failed

Please run this with the environment variable "G_DEBUG=fatal_warnings" and gather a backtrace of the critical error?

Looks like a NetworkManager library is causing the critical error.

I tested on a VM: qe-dell-ovs5-vm-9
DISTRO: RHEL-7.4-20170609.n.0 Workstation x86_64. 

I created several Veth network interfaces by using a script.
When I open control-center and select "Network", I choose Veth1, and click properties.
Then control-center stops working.

Created attachment 1287267 [details]
Diagnostic files from x86_64 VM

(In reply to Bastien Nocera from comment #7)
> (gnome-control-center:31072): libnm-CRITICAL **:
> ((libnm-core/nm-connection.c:1815)): assertion '<dropped>' failed
> 
> Please run this with the environment variable "G_DEBUG=fatal_warnings" and
> gather a backtrace of the critical error?
> 
> Looks like a NetworkManager library is causing the critical error.

Bastien, I would expect something like this:
https://paste.fedoraproject.org/paste/9ZLV1RwAjSnLtbYAST2h9Q

steps:
sudo ip link add veth0 type veth peer name veth1
sudo ip link set dev veth0 up
sudo ip link set dev veth1 up
nmcli device set veth1 managed yes
nmcli device set veth0 managed yes
nmcli connection add type ethernet ifname veth0 con-name ethie

now open c-c and press gear icon for both devices, it works for veth0 but there is a crash for veth1

Not sure who should make the check if device has a connection or not. Maybe NM (or it's libs) should take care about it.

It's not a crash, but a critical. It only happens with this version of gnome-control-center and the associated libnm, but not with a more recent g-c-c and libnma.

I've attached a patch to make it throw a warning earlier to avoid the critical, but the device still doesn't have a UUID, which I don't think g-c-c can do anything about:
https://bugzilla.gnome.org/show_bug.cgi?id=783998

I think we should just hide those types of devices in g-c-c, it's not the interface to set up and manage virtual clusters.

Created attachment 1290656 [details]
Diagnotic files from x86_64

I tested the newest version for control-center on a VM.

What is the hardware platform?
    x86_46, VM

What is the OS version, control-center version?
    RHEL 7.4 Workstation latest
    control-center-3.22.2-5.el7

What are the network interfaces: number and type?
    1 Ethernet interface
    9 Veth interfaces

    Veth interafaces are dynamically created via a script.
    # Create a network namespace for veth setup
    ip netns add vethsetup

    # Create 'internal' veth devices and hide their peers inside namespace
    for X in $(seq 1 9); do
        ip link add eth${X} type veth peer name eth${X}p
        ip link set eth${X}p netns vethsetup
    done

How do they appear in control-center?
    Ethernet interface is visible in the list. Veth interfaces are not visible.

Created attachment 1290657 [details]
Daignosti files from x86_64 on a laptop

I tested the newest version of control-center on a laptop.

What is the hardware platform?
    Physical machine - laptop Dell Precision M4700, x86_64.

What is the OS version, control-center version?
    RHEL 7.4 Workstation latest
    control-center-3.22.2-5.el7

What are the network interfaces: number and type?
    1 Ethernet interface - physical
    9 Veth interfaces

    Veth interafaces are dynamically created via a script.
    # Create a network namespace for veth setup
    ip netns add vethsetup

    # Create 'internal' veth devices and hide their peers inside namespace
    for X in $(seq 1 9); do
        ip link add eth${X} type veth peer name eth${X}p
        ip link set eth${X}p netns vethsetup
    done

How do they appear in control-center?
    Ethernet interface is visible in the list. Veth interfaces are not visible.

Created attachment 1290747 [details]
Daignostic files from x86_64 on a desktop PC

What is the hardware platform?
    Physical machine - desktop PC, x86_64

What is the OS version, control-center version?
    RHEL 7.4 Workstation Latest
    control-center-3.22.2-5.el7

What are the network interfaces: number and type?
    1 Ethernet - physical
    10 Veth interafaces

    Veth interfaces are created dynamically via a script.

How do they appear in control-center?
    I see all Veth interfaces in control-center.

They should not appear. If they appear, attach the output of "gnome-control-center -v network" here.

Created attachment 1290763 [details]
Diagnostic files from PPC64LE

What is the hardware platform?
    Physical machine, PPC64LE

What is the OS version, control-center version?
    RHEL 7.4 Workstation Latest
    control-center-3.22.2-5.el7

What are the network interfaces: number and type?
    1 Ethernet - physical
    10 Veth interafaces

    Veth interfaces are created dynamically via a script.

How do they appear in control-center?
    Ethernet interface is visible in the list. Veth interfaces are not visible.

Pavlin in c11 Bastien clearly said that Veth devices should be ignored by g-c-c, in other words they should not appear in the list. What is still unclear?

-Tom

I tested control-center on the latest RHEL 7.4
by using a physical machine having x86_64.
Veth interfaces are present, but does not appear in control-center.

Upgrading the component: control-center
    from version: 3.22.2-3.el7
      to version: 3.22.2-5.el7
has fixed the bug.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2096