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

[Tony Espy]

Binary package hint: network-manager

While testing how well hidden networks work in Ubuntu/Kubuntu Karmic Beta, I discovered that if you try to connect to a non-existent hidden network, that it takes a full 60 seconds to timeout / fail to connect.

I haven't actually looked at the code yet, but it should be possible to tell that the network doesn't exist in the time it takes to get a SSID-specific scan result back from wpa_supplicant.

ProblemType: Bug
Architecture: i386
CRDA: Error: [Errno 2] No such file or directory
Date: Thu Oct 8 15:21:49 2009
DistroRelease: Ubuntu 9.10
IfupdownConfig:
 auto lo
 iface lo inet loopback
IpRoute:
 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.106 metric 1
 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.104 metric 2
 169.254.0.0/16 dev eth0 scope link metric 1000
 default via 192.168.1.1 dev eth0 proto static
NonfreeKernelModules: nvidia wl
Package: network-manager 0.8~a~git.20091005t192303.1d28ad1-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
RfKill:
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
SourcePackage: network-manager
Uname: Linux 2.6.31-12-generic i686

[Thomas Hood (jdthood)]

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 "

[Thomas Hood (jdthood)]

Upstream status: RESOLVED NOTGNOME

[Mathieu Trudel-Lapierre (cyphermox)]

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.

[Launchpad Janitor (janitor)]

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