Failure timeout for connecting to hidden Wi-Fi network should be shorter than 60 seconds

lp292054_tune_supplicant_timeout_60s.patch

From: Alexander Sack <email address hidden>
Subject: Workaround driver/wpasupplicant slowness bug by giving association
 more time
Bug-Ubuntu: http://launchpad.net/bugs/292054

--- network-manager-0.8.1~beta1~git.20100510t073507.f3057a6.orig/src/nm-device-wifi.c 2010-05-10 19:39:11.000000000 +0000
+++ network-manager-0.8.1~beta1~git.20100510t073507.f3057a6/src/nm-device-wifi.c 2010-05-10 19:56:21.000000000 +0000
@@ -2792,7 +2792,7 @@
        priv = NM_DEVICE_WIFI_GET_PRIVATE (self);

        /* Set up a timeout on the connection attempt to fail it after 25 seconds */
- id = g_timeout_add_seconds (25, supplicant_connection_timeout_cb, self);
+ id = g_timeout_add_seconds (60, supplicant_connection_timeout_cb, self);
        if (id == 0) {
                nm_log_err (LOGD_DEVICE | LOGD_WIFI,
                            "Activation (%s/wireless): couldn't start supplicant "

Upstream status: RESOLVED NOTGNOME

Two years later, I'm actually of the idea that perhaps we should drop this patch as see who screams. It's not particularly hard to maintain, but if it's causing high delays in other areas, then the patch is already wrong -- not counting the fact that drivers have changed a lot since the time this was applied.

This bug was fixed in the package network-manager - 0.9.6.0~git201207161259.00297f4-0ubuntu1

---------------
network-manager (0.9.6.0~git201207161259.00297f4-0ubuntu1) quantal; urgency=low

  * upstream snapshot 2012-07-16 12:59:59 (GMT)
    + 00297f49fbbe05c51c02da43cda254c35e053589

  [ Edward Donovan ]
  * debian/source_network-manager.py: port package hook to python3.
    (LP: #1013171)

  [ Mathieu Trudel-Lapierre ]
  * debian/patches/lp292054_tune_supplicant_timeout_60s.patch: disable the
    patch. It adds unnecessary delays to things like detecting that hidden
    networks are not in range, and since Jaunty drivers have changed a lot.
    If we're still seeing timing issues with the supplicant, then perhaps the
    drivers should be fixed instead, or we'll re-enable the patch. (LP: #446623)
  * debian/network-manager.dnsmasq, debian/rules:
    install a config file to /etc/dnsmasq.d to avoid system-wide instances of
    dnsmasq to bind to 0.0.0.0 and the loopback interface, so that the NM-
    spawned instance can claim an IP on lo and provide local resolution.
    (LP: #959037)
  * debian/patches/add-veth-support.diff: add support for the veth* virtual
    ethernet devices. Thanks to Stéphane Graber for the patch.
  * debian/patches/nm-ip6-rs.patch: dropped, applied upstream.
  * debian/libnm-util2.symbols: add symbols:
    + nm_utils_file_is_pkcs12@Base
  * debian/control: move policykit-1 from Recommends to Depends: without it
    calls to the backend (e.g. when starting nm-tool), will fail. Thanks to
    Stéphane Graber for the testing and solution.
  * debian/rules: fix clean to properly remove m4/intltool.m4.
  * debian/tests/control, debian/tests/nm: add an autopkgtest control file and
    initial test to verify that NM works once installed.
  * debian/control: add XS-Testsuite: autopkgtest.
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 16 Jul 2012 17:17:51 -0400