fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-25 22:20:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

device: always cancel WPS when secret-request fails

Browse source 
See the logfile at [1], for how NetworkManager first attempts to connect
using WPS (which takes about 30 seconds). However, early on, the user logs
into KDE and a secret agent would register, which possibly could provide
secrets to connect. I think it is problematic to wait for WPS (which is
unlikely to succeed) if a secret agent shows up in the meantime.

A possible fix would be that when
  - WPS is pending
  - the secret request already failed
  - another secret-agent registers
then the activation (and WPS) is aborted and autoconnect may be tried
again, possibly with secrets provided by the new secret-agent.

However, this patch goes a step further: it always cancels activation
when the secret request fails. That means, WPS only works while the
user is also prompted for a secret. That makes sense to me, because
an action from the user is required. However, without secret prompt,
the user wouldn't be aware of that and is unlikely to press the WPS
push botton.

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1079672#c33

https://github.com/NetworkManager/NetworkManager/pull/216
This commit is contained in:
Thomas Haller 2018-10-01 14:43:17 +02:00
parent 15857ad958
commit 37c6cafb84
1 changed files with 30 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
src/devices/wifi/nm-device-wifi.c
View file

@ -1685,20 +1685,37 @@ wifi_secrets_cb (NMActRequest *req,
g_return_if_fail (nm_act_request_get_settings_connection (req) == connection);
if (error) {
_LOGW (LOGD_WIFI, "%s", error->message);
_LOGW (LOGD_WIFI, "no secrets: %s", error->message);
if (g_error_matches (error, NM_AGENT_MANAGER_ERROR,
NM_AGENT_MANAGER_ERROR_USER_CANCELED)) {
/* Don't wait for WPS timeout on an explicit cancel. */
nm_clear_g_source (&priv->wps_timeout_id);
}
if (!priv->wps_timeout_id) {
/* Fail the device only if the WPS period is over too. */
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_NO_SECRETS);
}
/* Even if WPS is still pending, let's abort the activation when the secret
* request returns.
*
* This means, a user can only effectively use WPS when also running a secret
* agent, and pressing the push button while being prompted for the password.
* Note, that in the secret prompt the user can see that WPS is in progress
* (via the NM_SECRET_AGENT_GET_SECRETS_FLAG_WPS_PBC_ACTIVE flag).
*
* Previously, WPS was not cancelled when the secret request returns.
* Note that in common use-cases WPS is enabled in the connection profile
* but it won't succeed (because it's disabled in the AP or because the
* user is not prepared to press the push button).
* That means for example, during boot we would try to autoconnect with WPS.
* At that point, there is no secret-agent running, and WPS is pending for
* full 30 seconds. If in the meantime a secret agent registers (because
* of logging into the DE), the profile is still busy waiting for WPS to time
* out. Only after that delay, autoconnect starts again (note that autoconnect gets
* not blocked in this case, because a secret agent registered in the meantime).
*
* It seems wrong to continue doing WPS if the user is not aware
* that WPS is ongoing. The user is required to perform an action (push button),
* and must be told via the secret prompt.
* If no secret-agent is running, if the user cancels the secret-request, or any
* other error to obtain secrets, the user apparently does not want WPS either.
*/
nm_clear_g_source (&priv->wps_timeout_id);
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_NO_SECRETS);
} else
nm_device_activate_schedule_stage1_device_prepare (device);
}