Bug 1316488 - Existing connection settings are not associated with new hot plugged interfaces
Existing connection settings are not associated with new hot plugged interfaces
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Beniamino Galvani
Fedora Extras Quality Assurance
: Reopened
: 1316592 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-10 06:04 EST by Marius Vollmer
Modified: 2016-03-26 14:01 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-1.2.0-0.7.beta2.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-26 14:01:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
[PATCH] device: fix handling of available connections (1.98 KB, patch)
2016-03-11 09:50 EST, Beniamino Galvani
no flags Details | Diff

  None (edit)
Description Marius Vollmer 2016-03-10 06:04:29 EST
Description of problem:

When hot plugging a new network interface while connection settings exist that match the new interface, NetworkManager fails to add those matching connections to the AvailableConnections D-Bus property. This used to happen on Fedora 23.

Version-Release number of selected component (if applicable):
NetworkManager-1.2.0-0.6.beta2.fc24.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a Fedora 24 VM.  We use this image:
   https://fedorapeople.org/groups/cockpit/images/fedora-24-9e30160225aa97bca1caf24c035ac61925da570e.qcow2.xz

2. nmcli connection add type ethernet ifname '*' con-name TEST mac 3.52:54:00:9e:00:F2
   nmcli connection modify TEST ipv4.method link-local

3. Add a new network interface to the VM with that mac.

4. nmcli device connect ensN
   where ensN is the name of the new interface

Actual results:
ensN is brought up with new, default connection settings and gets a address via DHCP.

Expected results:
ensN is brought up according to TEST, with a link-local address

Additional info:
I haven't actually verified the steps above... This happens in our integration tests and we can work around it by first adding the interface and then creating the connection.
Comment 1 Marius Vollmer 2016-03-10 06:34:13 EST
Update for reproduction steps

I have tested this with the linked image, and the behavior is essentially as described, with a little twist:

1. Create a Fedora 24 VM.  We use this image:
   https://fedorapeople.org/groups/cockpit/images/fedora-24-9e30160225aa97bca1caf24c035ac61925da570e.qcow2.xz

2. nmcli connection add type ethernet ifname '*' con-name TEST mac 3.52:54:00:9e:00:F2
   nmcli connection modify TEST ipv4.method link-local

3. Add a new network interface to the VM with that mac.

   NetworkManager will connect the new device, using TEST according to nmcli:

# nmcli device
DEVICE  TYPE      STATE      CONNECTION         
ens3    ethernet  connected  Wired connection 1 
ens9    ethernet  connected  TEST               
lo      loopback  unmanaged  --           

5. gdbus introspect -y -d org.freedesktop.NetworkManager -o /org/freedesktop/NetworkManager/Devices/M
   where M is the index for the new interface, most likely 2.

   AvailableConnections is empty, while I expect it to contain TEST.

6. nmcli device disconnect ensN
   where ensN is the name of the new interface

7. nmcli device connect ensN

   NetworkManager will create a new connection, called "ensN".

# nmcli c s
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  23201619-b2e0-4910-9d4d-9b9f2699a618  802-3-ethernet  ens3   
ens9                2057a599-f0af-4a0f-8089-3e8a7cbe5c7b  802-3-ethernet  ens9   
TEST                d1576574-ff36-4d0f-9554-5f0d061c71ae  802-3-ethernet  --     
ens2                07b98957-ba27-4cff-9a9d-ecac726ccb42  802-3-ethernet  --  

8. gdbus introspect -y -d org.freedesktop.NetworkManager -o /org/freedesktop/NetworkManager/Devices/M

   AvailableConnections now has one connection in it, ensN.

9. Reboot

10. gdbus introspect -y -d org.freedesktop.NetworkManager -o /org/freedesktop/NetworkManager/Devices/K
    where K is the index of the hotplugged interface, which is probably different now

    AvailableConnections is empty.  Thus NM didn't recognize its own "ensN" connection either after a reboot.

11. nmcli device disconnect ensN

12. nmcli device connect ensN

    NetworkManager again makes a new connection:

# nmcli c s
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  a8a43ea4-08e7-478c-9d22-0487acf9821d  802-3-ethernet  ens3   
ens9                40bfd174-738e-415d-b08a-a83b944075f7  802-3-ethernet  ens9   
TEST                d1576574-ff36-4d0f-9554-5f0d061c71ae  802-3-ethernet  --     
ens2                07b98957-ba27-4cff-9a9d-ecac726ccb42  802-3-ethernet  --     
ens9                2057a599-f0af-4a0f-8089-3e8a7cbe5c7b  802-3-ethernet  --
Comment 2 Marius Vollmer 2016-03-10 09:48:18 EST
Please also see bug 1316592, which might be a different symptom of the same bug.
Comment 3 Marius Vollmer 2016-03-11 03:48:51 EST
Here is another pattern that doesn't involve hotplug.

In a VM with a single network interface, the AvailableConnections property of that device is empty right after boot, but gets the correct value after "systemctl restart NetworkManager".

The single network interface is called "ens3" in my case, and it probably gets renamed from eth0 to ens3 during boot.  So maybe NM has trouble tracking interface renaming.
Comment 4 Beniamino Galvani 2016-03-11 09:50 EST
Created attachment 1135262 [details]
[PATCH] device: fix handling of available connections
Comment 5 Thomas Haller 2016-03-15 10:40:42 EDT
(In reply to Beniamino Galvani from comment #4)
> Created attachment 1135262 [details]
> [PATCH] device: fix handling of available connections

LGTM
Comment 6 Beniamino Galvani 2016-03-15 12:51:46 EDT
Patch applied to master, it will be included in the final release of NM 1.2:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ca5da5d80f3a21847bb807021e2e40d25bca50d0

Thanks for reporting this!
Comment 7 Beniamino Galvani 2016-03-15 13:02:59 EDT
*** Bug 1316592 has been marked as a duplicate of this bug. ***
Comment 8 Fedora Update System 2016-03-17 18:10:52 EDT
NetworkManager-1.2.0-0.6.beta2.1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e4d2697a0b
Comment 9 Fedora Update System 2016-03-18 10:56:23 EDT
NetworkManager-1.2.0-0.6.beta2.1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e4d2697a0b
Comment 10 Fedora Update System 2016-03-22 06:32:45 EDT
NetworkManager-1.2.0-0.7.beta2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e4d2697a0b
Comment 11 Fedora Update System 2016-03-22 12:56:09 EDT
NetworkManager-1.2.0-0.7.beta2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e4d2697a0b
Comment 12 Fedora Update System 2016-03-26 14:01:49 EDT
NetworkManager-1.2.0-0.7.beta2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

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