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 protected]> Mon, 16 Jul 2012 17:17:51
-0400
** Changed in: network-manager (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/446623
Title:
Failure timeout for connecting to hidden Wi-Fi network should be
shorter than 60 seconds
Status in NetworkManager:
Unknown
Status in “network-manager” package in Ubuntu:
Fix Released
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/446623/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
