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.
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 --
Please also see bug 1316592, which might be a different symptom of the same bug.
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.
Created attachment 1135262 [details] [PATCH] device: fix handling of available connections
(In reply to Beniamino Galvani from comment #4) > Created attachment 1135262 [details] > [PATCH] device: fix handling of available connections LGTM
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!
*** Bug 1316592 has been marked as a duplicate of this bug. ***
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
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
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
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
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.