summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLubomir Rintel <lkundrak@v3.sk>2022-08-30 12:55:24 +0200
committerLubomir Rintel <lkundrak@v3.sk>2022-09-05 09:40:07 +0200
commit833e92f9e944b04966b434218b53d088869e135b (patch)
tree15d62b3be3cd69556a2ae332c94eb38cc7c95db2
parent999d39944ea8968931c17f791294eded379001fa (diff)
downloadNetworkManager-833e92f9e944b04966b434218b53d088869e135b.tar.gz
manager: don't assume connection if device has ActRequest
The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other things, because it fails to assume an indicated connection after a restart. That seems to happen because after the decision to activate the indicated connection, the device does not move from DISCONNECTED state quickly enough. Another assumption recheck runs in between and decides to generate a connection, because the assume state was already reset in between. First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67 on vlan0017: NetworkManager (version 1.41.1-30921.55767cf5c5.el9) is starting... (asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) ... settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017" (45113870df0a4cfb/keyfile) Second start: NetworkManager (version 1.41.1-30921.55767cf5c5.el9) is starting... (after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) Assumption attempt successfully picks the right connection and thus proceeds to reset the assume state: manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017' (b3a61b68-f744-4a4c-a513-61399c154a67) (indicated) device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null) Everything great so far, activation of the right connection is enqueued and the device moves away from unavailable state. However, the activation can't proceed immediately: device (vlan0017): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') device (vlan0017): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'assume') active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0] device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier Now another assumption attempt is done. The original assume state is gone, so a connection is generated: platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959 device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6 manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9) keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as "/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection" (nm-generated,volatile,external) I think this shouldn't have happened. We've picked the correct connection already and it's enqueued for activation! Let's not assume anything if there's an activation request already. Fixes-test: @dracut_NM_vlan_over_team_no_boot
-rw-r--r--src/core/nm-manager.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/src/core/nm-manager.c b/src/core/nm-manager.c
index e21048bf79..b6b8b0b842 100644
--- a/src/core/nm-manager.c
+++ b/src/core/nm-manager.c
@@ -3101,6 +3101,14 @@ recheck_assume_connection(NMManager *self, NMDevice *device)
return FALSE;
}
+ if (nm_device_get_act_request(device)) {
+ /* The device might might not have progressed beyond
+ * NM_DEVICE_STATE_DISCONNECTED (checked above), because it might
+ * be pending a carrier check. */
+ _LOG2D(LOGD_DEVICE, device, "assume: don't assume because there's an activation request");
+ return FALSE;
+ }
+
sett_conn = get_existing_connection(self, device, &generated);
/* log no reason. get_existing_connection() already does it. */
if (!sett_conn)