On 06/08/2016 05:33 PM, Dan Williams wrote:
On Wed, 2016-06-08 at 16:24 -0400, Tony Espy wrote:
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
Gbp-Pq: Name Clear-WiFi-requested_scan-if-suppl-goes-INACTIVE.patch
---
src/devices/wifi/nm-device-wifi.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/devices/wifi/nm-device-wifi.c b/src/devices/wifi/nm-
device-wifi.c
index bacd5e6..f6325a6 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -1903,6 +1903,21 @@ supplicant_iface_state_cb
(NMSupplicantInterface *iface,
else
_LOGI (LOGD_DEVICE | LOGD_WIFI, "supplicant
interface keeps failing, giving up");
break;
+ case NM_SUPPLICANT_INTERFACE_STATE_INACTIVE:
I'd say we make this simpler; if the supplicant enters inactive state
that usually means either RFKILL or no enabled networks. So we can
just do all this unconditionally:
priv->requested_scan = FALSE;
nm_clear_g_source (&priv->pending_scan_id);
request_wireless_scan (self, NULL);
Do you think that would work?
Yes. I'll change and re-send.
/tony
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
