Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1512316 - Unmanaged dummy becomes managed when IP address is set
Summary: Unmanaged dummy becomes managed when IP address is set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
: 1523572 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-12 17:51 UTC by Petr Horáček
Modified: 2018-04-10 13:35 UTC (History)
11 users (show)

Fixed In Version: NetworkManager-1.10.2-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 13:34:16 UTC


Attachments (Terms of Use)
device: start managing external devices on reapply (deleted)
2017-11-16 09:02 UTC, Beniamino Galvani
no flags Details | Diff
device: don't touch external devices (deleted)
2017-11-16 09:03 UTC, Beniamino Galvani
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0778 None None None 2018-04-10 13:35:11 UTC

Description Petr Horáček 2017-11-12 17:51:28 UTC
Description of problem:
NetworkManager takes over an unmanaged dummy interface when IP address is set on it. When a user removes this address (via `ip address del`), NetworkManager sets it back. That is unexpected since the interface was never set as managed.


Version-Release number of selected component (if applicable):
CentOS Linux release 7.4.1708 (Core) 
NetworkManager-1.8.0-11.el7_4.x86_64


How reproducible:
Always


Steps to Reproduce:
# ip link add dummy_4 type dummy
# nmcli dev | grep dummy_4
dummy_4      dummy     unmanaged  --          
# ip link set up dev dummy_4
# nmcli dev | grep dummy_4
dummy_4      dummy     unmanaged  --          
# ip address add 2001:99::1/64 dev dummy_4
# nmcli dev | grep dummy_4
dummy_4      dummy     connected  dummy_4     
# nmcli con | grep dummy_4
dummy_4      d0385cac-0b7d-488a-8f12-8e2fd7e2a9ce  dummy           dummy_4

Actual results:
Unmanaged interface becomes managed.


Expected results:
Interface remains unmanaged until explicitly added to NetworkManager.

Comment 2 Thomas Haller 2017-11-13 11:29:47 UTC
when you add a software-device (like dummy, bridge, bond) outside of NM, NM recognizes that it was added outside of NetworkManager. As long as it has no IP addresses, NM marks it as unmanaged.

Once you externally up the interface, and add IP addresses, NM will generate an external connection to represent that something is active on the device. That does not involve touching the device or interfering with it.

When you remove the IP address, NM will cleanup  the generated connection, and mark the device as unmanaged again.

To avoid that, configure the device as explicitly unmanaged by one of the various means:
 - ENV{NM_UNMANAGED}="1" in udev
 - device*.managed = `man NetworkManager.conf`
 - nmcli device set "$DEV" managed no (this way does not persist across 
     reboot, but across restart of the service)
 - NM_CONTROLLED=no in an ifcfg file
 - keyfile.unmanaged-devices in `man NetworkManager.conf` (deprecated)
Unless you do that, NM behaves as explained above.


Does that cause a problem for you?

Comment 3 Petr Horáček 2017-11-13 14:58:49 UTC
Yay, sorry, my reproducer does not reflect the problem. It looks like NM does set the IP back. Here is a new reproducer. With NM running, it fails in a second (found ipv6 address after ipv6 del). With NM stopped, it runs without an error.

#!/usr/bin/bash

DUMMY=dummy_111

function set_up {
    ip l add $DUMMY type dummy
    ip l set up dev $DUMMY
}

function tear_down {
    ip l del $DUMMY
}

function test_add_del_addr {
    tear_down
    set_up

    ip a add 192.168.212.212/24 dev $DUMMY
    ip a | grep -q '192.168.212.212/24' || { echo missing ipv4 address after ipv4 add; exit 1; }

    ip a add 2002:99::1/64 dev $DUMMY
    ip a | grep -q '192.168.212.212/24' || { echo missing ipv4 address after ipv6 add; exit 1; }
    ip a | grep -q '2002:99' || { echo missing ipv6 address after ipv6 add; exit 1; }

    ip a del 2002:99::1/64 dev $DUMMY
    ip a | grep -q '192.168.212.212/24' || { echo missing ipv4 address after ipv6 del; exit 1; }
    ip a | grep -q '2002:99' && { echo found ipv6 address after ipv6 del; exit 1; }

    ip a del 192.168.212.212/24 dev $DUMMY
    ip a | grep -q '192.168.212.212/24' && { echo found ipv4 address after ipv4 del; exit 1; }
    ip a | grep -q '2002:99' && { echo found ipv6 address after ipv4 del; exit 1; }
}

for i in `seq 1 100` :; do
    test_add_del_addr
done

Comment 4 Beniamino Galvani 2017-11-16 09:02:53 UTC
Created attachment 1353316 [details]
device: start managing external devices on reapply

In the next commit we will modify ipX_config_merge_and_apply to never
touch external devices. When a "reapply" call is issued on an external
device we are no longer simply tracking its state but we are actively
managing it and so its sys-iface-state must be promoted to managed.

Comment 5 Beniamino Galvani 2017-11-16 09:03:10 UTC
Created attachment 1353317 [details]
device: don't touch external devices

If a device is 'external' (which means that NM generated an in-memory
connection to only to track the device state) we should not change its
IP configuration.

Comment 6 Thomas Haller 2017-11-16 09:08:08 UTC
both lgtm.

Comment 8 Jaroslav Aster 2017-12-18 11:26:01 UTC
*** Bug 1526021 has been marked as a duplicate of this bug. ***

Comment 10 Vladimir Benes 2018-01-17 09:18:04 UTC
automated, test running and passing

Comment 11 Beniamino Galvani 2018-01-18 14:20:56 UTC
*** Bug 1523572 has been marked as a duplicate of this bug. ***

Comment 14 errata-xmlrpc 2018-04-10 13:34:16 UTC
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-2018:0778


Note You need to log in before you can comment on or make changes to this bug.