From 14d429dd17dcc242f13403374a519d3ea17df261 Mon Sep 17 00:00:00 2001 From: Thomas Haller Date: Mon, 17 Apr 2023 11:42:19 +0200 Subject: [PATCH] device: block autoconnect of profile when deleting device Currently, when we delete a device then autoconnect does not kick in right away. But that is only, because we happen not to schedule a "autoactivate" recheck. What should be happen, is that rechecking whether to autoconnect is always allowed, and that we have the necessary state to know that autoconnect currently should not work. Instead, block autoconnect of the involved profile. That makes sense, because clearly we don't want to autoconnect right again after `nmcli device delete $iface`. --- src/core/devices/nm-device.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/core/devices/nm-device.c b/src/core/devices/nm-device.c index 0a1e4fdddd..25b53ee345 100644 --- a/src/core/devices/nm-device.c +++ b/src/core/devices/nm-device.c @@ -13568,7 +13568,8 @@ delete_cb(NMDevice *self, GError *error, gpointer user_data) { - GError *local = NULL; + NMSettingsConnection *sett_conn; + GError *local = NULL; if (error) { g_dbus_method_invocation_return_gerror(context, error); @@ -13584,6 +13585,19 @@ delete_cb(NMDevice *self, /* Authorized */ nm_audit_log_device_op(NM_AUDIT_OP_DEVICE_DELETE, self, TRUE, NULL, subject, NULL); + sett_conn = nm_device_get_settings_connection(self); + if (sett_conn) { + /* Block profile from autoconnecting. We block the profile, which may + * be ugly/wrong with multi-connect profiles. However, it's not + * obviously wrong, because profiles for software devices tend not to + * work with multi-connect anyway, because they describe a (unique) + * interface by name. */ + nm_settings_connection_autoconnect_blocked_reason_set( + sett_conn, + NM_SETTINGS_AUTOCONNECT_BLOCKED_REASON_USER_REQUEST, + TRUE); + } + if (!nm_device_unrealize(self, TRUE, &local)) { g_dbus_method_invocation_take_error(context, local); return;