[PATCH] wifi: don't remove AP upon link lost event

[Daniel Drake <dsd laptop org>]

When the link is lost, it doesn't mean that the AP has gone away.
It might just be overloaded or have rejected an association attempt
for an temporary reason.

The behaviour described in the comment removed here was not true
in such circumstances. As the supplicant never "loses sight" of the AP,
further scans will not generate "new BSS" signals for this AP, which is
what would be needed for the the AP to be found again in the next scan.

Instead, just leave the AP in the list and trust wpa_supplicant to handle
this case.

Fixes a bug where my unreliable AP sometimes rejects association
momentarily, but upon such event, NM was removing the network from the
list and never readding it, which left me unable to attempt to reconnect.
---
 src/devices/nm-device-wifi.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/src/devices/nm-device-wifi.c b/src/devices/nm-device-wifi.c
index 2b8ddd1..2340509 100644
--- a/src/devices/nm-device-wifi.c
+++ b/src/devices/nm-device-wifi.c
@@ -2180,19 +2180,7 @@ link_timeout_cb (gpointer user_data)
        if (nm_device_get_state (dev) != NM_DEVICE_STATE_ACTIVATED)
                return FALSE;
 
-       /* Remove whatever access point we used to be connected to from the list
-        * since it failed and might no longer be visible.  If it's actually still
-        * there, we'll find it in the next scan.
-        */
-       if (priv->current_ap) {
-               ap = priv->current_ap;
-               priv->current_ap = NULL;
-       } else
-               ap = nm_device_wifi_get_activation_ap (self);
-
-       if (ap)
-               remove_access_point (self, ap, TRUE);
-
+       priv->current_ap = NULL;
        nm_device_state_changed (dev,
                                 NM_DEVICE_STATE_FAILED,
                                 priv->ssid_found ? NM_DEVICE_STATE_REASON_SUPPLICANT_TIMEOUT :
-- 
1.8.1.4