NetworkManager slow to reconnect after resume from suspend; manual "iwlist eth1 scanning" fixes it -- wl/broadcom drivers

[Marc Jauvin]

Binary package hint: network-manager-gnome

On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network Manager usually takes around 1 minute before trying to reconnect to my WiFi router. I noticed that if I run the following command:

# iwlist eth1 scan

Network Manager seems to "wake-up" right after the scan is complete and connects right away.

Would there be a way to send a signal upon resume that would trigger the same "wake-up" call?

*** I'm running Intrepid Ibex updated multiple time a day.

[Jeffrey Baker (jwbaker)]

Do you happen to have hardware scanning disabled in your module parameters?

[Marc Jauvin (marc-r4l)]

According to 'modinfo iwl3945', the default is scanning enabled, and I
don't see anywhere that overrides this, so I would think this is not
the case. Do you have an easy way to check this?

Jeffrey Baker <email address hidden> wrote:

> Do you happen to have hardware scanning disabled in your module
> parameters?
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager-applet” source package in Ubuntu: New
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500
http://register4less.com

[Jeffrey Baker (jwbaker)]

On Fri, Sep 26, 2008 at 5:02 AM, Marc Jauvin <email address hidden> wrote:

> According to 'modinfo iwl3945', the default is scanning enabled, and I
> don't see anywhere that overrides this, so I would think this is not
> the case. Do you have an easy way to check this?
>

You would know if it was disabled, because you have to do it manually.

I asked because I had long n-m wait to associate in Hardy, but it's instant
in Intrepid i.e. basically the opposite of your problem. I suspect this bug
is in iwl3945, not in n-m.

[Marc Jauvin (marc-r4l)]

OK, thanks for this info.

Anybody else using iwl3945 that experience (or not) this problem?

Jeffrey Baker <email address hidden> wrote:

> On Fri, Sep 26, 2008 at 5:02 AM, Marc Jauvin <email address hidden> wrote:
>
>> According to 'modinfo iwl3945', the default is scanning enabled, and I
>> don't see anywhere that overrides this, so I would think this is not
>> the case. Do you have an easy way to check this?
>>
>
> You would know if it was disabled, because you have to do it manually.
>
> I asked because I had long n-m wait to associate in Hardy, but it's instant
> in Intrepid i.e. basically the opposite of your problem. I suspect this bug
> is in iwl3945, not in n-m.
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager-applet” source package in Ubuntu: New
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500
http://register4less.com

[Marc Jauvin (marc-r4l)]

This thread is related to the problem:

   http://www.nabble.com/iwl3945-delayed-scan-results-after-resume-td19154238.html

[Marc Jauvin (marc-r4l)]

Here are the log entries in /var/log/daemon. You'll see that it takes over 30 seconds to reconnect.

Note: on some occasions, the reconnect has already completed when I come out of the lock screen after resume.

[svasie (svasie)]

I can confirm this.

Sometimes reassociation is instant, sometimes it takes a long time to associate. If you click on network-manager-applet while waiting, no ESSIDs are shown.

[Alexander Sack (asac)]

does this problem occur when you sleep your computer at one place and wake up at a different place (with different AP), or also if you wake up at the same AP?

[Alexander Sack (asac)]

could be related to bug 264683 if thats the case.

[Marc Jauvin (marc-r4l)]

No, the computer is on my desk, and I just suspend/resume without
moving an inch.

Alexander Sack <email address hidden> wrote:

> does this problem occur when you sleep your computer at one place and
> wake up at a different place (with different AP), or also if you wake up
> at the same AP?
>
> ** Changed in: network-manager (Ubuntu)
> Status: New => Incomplete
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Blu (blutack)]

This is also an issue for the iwl3945 on a HP dv6000, and has been for every Ubuntu release I've ever used.
As the previous poster says, the workaround is to run sudo iwlist scanning after the resume, after which networkmanager immediately connects.

[Marc Jauvin (marc-r4l)]

Are you running a "fresh" install of Intrepid? Personnally, It's an
upgrade from Hardy, and I sometime wonder if a fresh install would
behave the same.

Blutack <email address hidden> wrote:

> This is also an issue for the iwl3945 on a HP dv6000, and has been
> for every Ubuntu release I've ever used.
> As the previous poster says, the workaround is to run sudo iwlist
> scanning after the resume, after which networkmanager immediately
> connects.
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Marc Jauvin (marc-r4l)]

I did a fresh install with Intrepid 64bit and it behaves exactly the same.

[jrtokarz (jrtokarz1)]

I have recently switched from KDE to Gnome and I have found that NetworkManager is much slower than KNetworkManager at reconnecting.

[Ludovico Cavedon (cavedon)]

Same problem for me; I have 8.10 with an Intel 3945abg card (iwl3945 driver) in an HP laptop.
If I run "sudo iwlist scan" network manager wakes up afrter a few seconds.
Note that I need to run it with sudo, otherwise as a non-root user the wireless card won't do a channel-hopping scan, so it won't find all the networks.
Thanks!

[Alexander Sack (asac)]

so seems like this flipped in 0.7 ...previously it was slow to connect to network when waking up at the same locaiton, now we have slow reconnection when we wake up at a different location (bug 264683).

do you see this in intrepid also when resuming at the same location?

[Marc Jauvin (marc-r4l)]

Yes, I almost allways resume where I suspended. So it's not related to
the location. Sometime it will be reconnected when I'm finished typing
my password after resuming, sometime it will take ~30sec to reconnect.

Alexander Sack <email address hidden> wrote:

> so seems like this flipped in 0.7 ...previously it was slow to connect
> to network when waking up at the same locaiton, now we have slow
> reconnection when we wake up at a different location (bug 264683).
>
> do you see this in intrepid also when resuming at the same location?
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Paul Bourke (pauldbourke)]

Id like to jump on this bug also.. am using the 'wl' wireless driver on Ubuntu Intrepid.
Wireless/suspend works great, but wireless takes a good 20-30 seconds to re-enable on wake. I thought this was normal behavior until only recently when I started wondering is there any way to make it faster.. Any info on a fix please let us know!

[Marc Jauvin (marc-r4l)]

If only more people like you would step forward... It's been bugging
me for a while, but it's as if we're a minority (even though intel
wifi cards are quite common these days).

Thanks.

Paul Bourke <email address hidden> wrote:

> Id like to jump on this bug also.. am using the 'wl' wireless driver
> on Ubuntu Intrepid.
> Wireless/suspend works great, but wireless takes a good 20-30
> seconds to re-enable on wake. I thought this was normal behavior
> until only recently when I started wondering is there any way to
> make it faster.. Any info on a fix please let us know!
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Paul Bourke (pauldbourke)]

I have a theory that depsite the above comments that it may be wpa-supplicant or the intel driver itself, it actually is just network-mananger.
I have just tried switching to Wicd (wicd.sourceforge.net) and it seems much faster reconnecting on wake.
Maybe some others would like to try this and post their results?

[Marc Jauvin (marc-r4l)]

YES, finally, you made my day!!!

I tried wicd in the past, but I didn't like it. Looks like it improved
quite a bit as it now works beautifully, and I'm reconnected within a
few seconds after resume.

Thanks!

Paul Bourke <email address hidden> wrote:

> I have a theory that depsite the above comments that it may be
> wpa-supplicant or the intel driver itself, it actually is just
> network-mananger.
> I have just tried switching to Wicd (wicd.sourceforge.net) and it
> seems much faster reconnecting on wake.
> Maybe some others would like to try this and post their results?
>
> --
> network manager slow to reconnect after suspend/resume
> https://bugs.launchpad.net/bugs/274405
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: network-manager-gnome
>
> On my Thinkpad T61 with Intel 3945abg (iwl3945 driver), Network
> Manager usually takes around 1 minute before trying to reconnect to
> my WiFi router. I noticed that if I run the following command:
>
> # iwlist eth1 scan
>
> Network Manager seems to "wake-up" right after the scan is complete
> and connects right away.
>
> Would there be a way to send a signal upon resume that would trigger
> the same "wake-up" call?
>
> *** I'm running Intrepid Ibex updated multiple time a day.
>

--
Marc Jauvin
514-905-6500 ext. 403
http://register4less.com

[Paul Bourke (pauldbourke)]

Great stuff :) Seems we can just use wicd for now and wait for a nm fix. Though I'm quite liking wicd, may not bother switching back.
Merry Christmas!

p.s. (lol @ tracking bugs on Christmas day.. try finding a Microsoft employee who's that passionate about their OS ;))

[hackel (hackel)]

I also am experiencing this with my BCM4312 (non-free wl driver) on my Dell Mini 9. When resuming from hibernation, it takes about 1 minute from the time my desktop appears before NM wakes up and scans for networks and connects. Here's an excerpt from my syslog after waking up:

Jan 3 17:48:31 mini NetworkManager: <info> Waking up...
>> removed bits about wired interface eth0 <<
Jan 3 17:48:31 mini NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/b
ugs/191889)
Jan 3 17:48:31 mini NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/b
ugs/191889)
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): now managed
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): device state change: 1 -> 2
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): preparing device.
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): deactivating device (reason: 2).
Jan 3 17:48:31 mini NetworkManager: <WARN> nm_device_wifi_disable_encryption(): error setting key for device eth1: Invalid argument
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): device state change: 2 -> 3
Jan 3 17:48:31 mini acpid: client connected from 4707[0:0]
Jan 3 17:48:31 mini NetworkManager: <info> (eth1): supplicant interface state change: 1 -> 2.
Jan 3 17:48:35 mini kernel: [64287.088083] eth1: no IPv6 routers present
Jan 3 17:48:56 mini NetworkManager: <info> Activation (eth1) starting connection 'Auto Boingo Hotspot'
At this point it connects...

The computer was initially suspended while connected to the same unencrypted access point.

If there is any other information I can provide, let me know.

[granjerox (granjerox)]

Same problem here iwl3945 takes min. 30seg to reconnect after
resuming from suspend.

[Mikael Honkala (mikael-honkala)]

Same problem with HP Pavilion tx2000 and the Ubuntu-provided Broadcom STA wireless driver.
Reconnect after suspend worked fine in Hardy, but has always taken a long time under 8.10. Sometimes wireless is completely disabled after suspend.
Seems to be NM problem, since wicd reconnects in just a few seconds with same drivers and hardware.

[Jonas Finnemann Jensen (jopsen)]

I have a similar issue using iwlagn it takes at least 30 seconds from resume to reconnect... Sometimes even from boot, if the wireless network wasn't up when the PC was started... By the way, I think it's a network manager issue, as it feels like it affects wired network too..

[dlstyley (deaston)]

Same with Acer Extensa 4420, wl driver, and Network Manager on Intrepid for AMD64.

[overlooking (mhnin0)]

Same problem on a T-61 w/ iwlagn, Intrepid, and Network Manager. Switching to Wicd seems to have fixed the problem.

[Marc Jauvin (marc-r4l)]

Updating to kernel 2.6.27-14-generic fixes this completely!

Now this is working as expected and connecting as soon as I resume.

[Mikael Honkala (mikael-honkala)]

Cannot confirm the above. I am now on Jaunty with 2.6.28-11 kernel, and Network Manager is still slow to reconnect after suspend/resume. If I understand correctly, this problem only affects those who have upgraded from Hardy to Intrepid without a full install?

[Tuyphon (tuyphon)]

I believe the problem scope is wider. I have this issue with two laptops, running fresh installs of Intrepid and Jaunty (beta).

[Mikael Honkala (mikael-honkala)]

Yes. I can confirm that. I have a fresh install of Jaunty now, and the wifi is slow to connect after suspend/resume, but normal after login.

Can I provide some files etc. for debug?

[tlois (tlois3)]

OK- here's one: on an upgrade to jaunty with thinkpad t30, works fine. like better than ever- is connected before the icon even pops up. on fresh install of jaunty on my eee box, takes very long to reconnect- my router does not even show up for a while. i will see if taking out wpa encrytion helps. had some problems connecting to wpa at all at first.

[tlois (tlois3)]

Taking router off WPA encryption did nothing for the problem, but that is all I have messed on the eee with Jaunty, so thought i'd give it a shot.

Installed WICD and that is working as it should on suspend with wireless. Takes a little bit to get used to the change, but does work- the suspend back to reconnect is a big one for me, as I am always jumping on and off that computer, but def need it to go to suspend.

[Paul Hinze (phinze)]

Same behavior on latest Jaunty on a MacBookPro4,1... 20-30 seconds to reconnect to WiFi after resume. Will try WICD as suggested above and see if that works any better.

[Colin Leroy-Mira (colin-colino)]

Removing incomplete status as the answer has been provided; this should be "confirmed" given the number of people affected (me included, iwl3945, resuming in same location or not).

[aysiu (ubuntubugzilla-psychocats)]

I had no luck with WICD.

This workaround is a little messy, but it seems to work better than nothing.

sudo nano -B /usr/lib/pm-utils/sleep.d/45iwlist

Then edit it so that the command "iwlist scan" is part of the process:

#!/bin/sh
# Kludge to force a rescan of available wireless networks on resume, so that
# stale ESSIDs aren't shown as current.
# To be removed when bug #336055 is resolved in the kernel.

. "${PM_FUNCTIONS}"

which iwlist || exit $NA

rescan_wireless()
{
 for iface in /sys/class/net/*; do
  [ -d "$iface/wireless" ] || continue
  iface="${iface##*/}"
  iwlist "$iface" scanning
 done
}

case "$1" in
 thaw|resume)
  rescan_wireless
  iwlist scan
  ;;
 *) exit $NA
  ;;
esac

Then Control-X, Y, Enter to save.

I'm on an HP 1120nr

[Mikael Honkala (mikael-honkala)]

Implemented the addition of "iwlist scan" as described above. No chance, reconnect still takes at least half a minute.

Wicd works fine for me, but lacks the state-of-the-art 3G features of the Network Manager.

If anyone has the time, you could compare syslog entries on wakeup for both WICD and NM, in case there are some significant differences.

(On HP tx2020eo.)

[Thor H. Johansen (thorhajo)]

Can confirm the problem with Jaunty Jantalope on MacBook Air 1,1 with wl driver. Takes quite long before it connects.

Speaking of slow things, why is DHCP always slow, on all computer platforms? You'd think that with ping times of 1-2 ms, a DHCP request could be served in less than 4 ms? Connecting to a network with a static IP is near instantaneous. Where does this slowness originate? Am I waiting 5-7 seconds for my DHCP handshakes because of slow poll intervals? It seems to especially happen with wireless access points, as DHCP over Ethernet seems somewhat quicker.

[Mat Tomaszewski (mat.t.)]

This is a software issue, not a design issue - marking invalid as papercut

[hackel (hackel)]

Yes, definitely a software issue. It should be trivial to trigger NM to do a search for access points when resuming. It's not a hardware issue, as an "iwlist scan" functions immediately after resuming.

Though it seem to meet all of the conditions for 100 paper cuts:
- bugs that are system-wide
- bugs that impact standard workflows (like connecting to the network...)
- bugs that are easy to address, rather that ones that require significant design or development efforts
- issues with existing features, rather than requests for new features
- bugs that relate to usability and design, rather than broken software

It seems to me that forcing users to wait 30-60 seconds every time they open their notebook is quite a big usability concern.

[Sancho Panza (prashanthr-deactivatedaccount-deactivatedaccount)]

@ hackel: 30-60 seconds is more like an average time. I have had instances when I had to wait a few minutes
(despite using "iwlist scan" immediately on resuming from suspend or restarting network manager and networking daemons).

@ Mat: I agree this may not be a design issue, but as Hackel pointed out, it is a usability issue and meets all other conditions of 100 paper cuts.

[David Siegel (djsiegel-deactivatedaccount)]

I agree, this affects usability greatly, although there is no real design decision to be made here. Yes, make reconnecting to the network work faster. Speeding up reconnecting to a network is not a design issue, unless it is slow by design. The speed up that you seek would come with improved engineering, which by all means should be done. For example, faster booting affects usability tremendously, but is fundamentally a technology driven issue, not a design driven issue.

Also, I only see speculation that this is trivially fixable, in the sense that there's one setting or one line of code in network-manager that we could change to make the connection establish more quickly. As a programmer, my intuition is that this bug requires some expertise to fix.

[Mat Tomaszewski (mat.t.)]

Sancho Panza wrote:
> @ hackel: 30-60 seconds is more like an average time. I have had instances when I had to wait a few minutes
> (despite using "iwlist scan" immediately on resuming from suspend or restarting network manager and networking daemons).
>
> @ Mat: I agree this may not be a design issue, but as Hackel pointed
> out, it is a usability issue and meets all other conditions of 100 paper
> cuts.

It is a valid issue and a bug that needs fixing. There's a difference
however, between the usability issues that originate from bad design
decisions and issues that are purely related to the performance of the
software. An app being slow quite obviously impacts the overall
satisfaction and efficiency, thus the usability in general, but in this
project we want to concentrate on the issues that have their roots in
the suboptimal design, rather than the software performance or reliability.

[hackel (hackel)]

You are right, I am certain that it is more involved than a single line of code. It seems that NM is not scanning for new networks automatically after a resume, but only on it's usual timed schedule, and I would expect it to be simple enough to trigger this kind of a scan through a dbus signal when resuming or something. (see http://www.nabble.com/Export-%22scan-now%22-command-over-D-Bus-td22731714.html) It may also be that wpa_supplicant is actually at fault, since I believe NM is relying on this for scanning. I have not looked at the code at all, however.

[timmy (timmy-mailinator)]

David Siegel wrote:
> I agree, this affects usability greatly, although there is no real design decision to be made here. Yes, make reconnecting > to the network work faster. Speeding up reconnecting to a network is not a design issue, unless it is slow by design. The > speed up that you seek would come with improved engineering, which by all means should be done. For example, faster > booting affects usability tremendously, but is fundamentally a technology driven issue, not a design driven issue.
>
> Also, I only see speculation that this is trivially fixable, in the sense that there's one setting or one line of code in
> network-manager that we could change to make the connection establish more quickly. As a programmer, my intuition
> is that this bug requires some expertise to fix.

9 months on this bug and that's all you have to offer.
I'm sorry, but no one wants to hear your two cents. We know it's not a design issue, it's a bug and is logged as such. Some people are actually getting slightly annoyed this still exists.

[David Siegel (djsiegel-deactivatedaccount)]

Timmy, this bug was wrongly added to the hundredpapercuts project only hours ago. I am not upstream, I am only responsible for identifying small design issues to be added to the hundredpapercuts project. I am an Ubuntu user too, and I experience this bug every day and would like to see it fixed, but it doesn't belong in hundredpapercuts.

I see you just joined Launchpad today and have participated on only one bug, while I have been working on improving Ubuntu every day for the last few years. If you really want to see this bug fixed, get to work, or at least do not interfere with the people who are actually working on improving these issues. If you really want to see this bug fixed, I recommend contacting the maintainer of network-manager, and offering a $100 bounty to fix this issue ASAP if you are not able to make the fix yourself.

[Mikael Honkala (mikael-honkala)]

Workaround tested on HP tx2020eo:

Step 1: Unchecking and checking the "Enable wireless" setting in the NM taskbar icon (right click) immediately starts the scan and connection.

Step 2: Requesting the same via the command line through the following works as well:

dbus-send --system --type=method_call --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.DBus.Properties.Set string:org.freedesktop.NetworkManager string:WirelessEnabled variant:boolean:false
dbus-send --system --type=method_call --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.DBus.Properties.Set string:org.freedesktop.NetworkManager string:WirelessEnabled variant:boolean:true

Step 3: Putting the above two lines in /etc/acpi/resume.d/92-kick-network-manager.sh with appropriate permissions works, starting the wireless connection on resume.

[psychoelf (psychoelfx)]

This bug affects both the 3945ABG and 4965AGN chips. I can verify it on 9.04 on both. Thirty seconds isn't really a big concern, but when OSX and Win7 are both near instant, it makes it hard to switch people over as most people see 30 seconds as a lifetime. I just switched my wife to using Linux and she asked me why it wasn't instant like Vista. Considering she is constantly closing the lid on her laptop to chase our 2 year old, and she doesn't have a lot of time to herself, that 30 seconds may be her only chance to check email. :)

[PomCompot (pomme-compote-launchpad)]

Same problem but a startup.

Can confirm almost the same problem on a Dell Inspiron 1520 (iwl3945). Have to wait from 30s to 3min before connection is done. Happen on my WPA encrypted network with only this laptop. Non problem with others and apparently no problem with this laptop on another WPA network (needs investigations to confirm).

[inigopete (inigopete)]

Running 9.04 on a Dell Mini 10v (Atom 270).

I'm now using wicd: the wait after waking for re-connection has reduced to around 10s from 40s.

Which is nice.

[Nick Hurley (todesschaf)]

Happens for me on a MacBook Pro 5,1 using the wl driver under 9.04. This happens on multiple wlans, whether or not I've moved from one to the other after suspend. For me, wicd does not appear to be an option, as it constantly is dropping the connection and reconnecting.

[Mikael Honkala (mikael-honkala)]

Finally! Running 9.10 Karmic Beta. Network Manager starts reconnecting immediately after resume, like it used to in 8.04 Hardy.

[hackel (hackel)]

This also seems to be fixed for me in 9.10.

[cosmix (cosm7x)]

This is not universally fixed on Karmic. Unless this is a separate driver issue with identical symptoms, the bug persists. Specifically, on an HP Mini 2140 (wl driver, BCM4322 chipset) it still takes around 30 sec. on average to reconnect on wake with a fully updated Karmic as of the time of writing this.

[hackel (hackel)]

I will mention one other experience i have had since upgrading, but this may be a separate issue. Sometimes (not always) when I resume it will take it a long time to realize that the old AP is gone....eventually it will disconnect, though. It will then either immediately try to reconnect to the new one, or simply stop in a disconnected state. I have not been able to reproduce this behaviour reliably. It may just be when I'm in a new location, I'm still not sure. Either way, it has the same effect of taking a long time to re-connect. Still an improvement though!

[aysiu (ubuntubugzilla-psychocats)]

The problem seemed to go away for Karmic, but I just upgraded to Lucid Alpha 3, and it's back again. It's taking well over 30 seconds for wireless to reconnect after a resume from suspend.

Any logs or anything you would like me to post, let me know.

[zoomy942 (zoomy942)]

not only can it take a long time but if you go from one network to another while in sleep, it may not connect at all.

[aysiu (ubuntubugzilla-psychocats)]

Still happening.

In dmesg | tail, I see these messages:

sky2 eth0: disabling interface
ADDRCONF(NETDEV_UP):
eth0: link is not ready
eth1: no IPv6 routers present

Any idea what that means?

[Brian Brunswick (brian-ithil)]

Same for me on lucid. If I manually reselect network though it works immediately, but not for long time otherwise.

[aysiu (ubuntubugzilla-psychocats)]

A little better after release, but still too long. It takes between 15 and 25 seconds to reconnect after resume from suspend-to-RAM. That's about the same time it takes me to cold boot my netbook. What's the point of suspend-to-RAM, then?

This is what I get from dmesg | tail now:
[ 8150.796717] ata1.00: configured for UDMA/66
[ 8150.908266] usb 1-4: reset high speed USB device using ehci_hcd and address 2
[ 8151.079594] PM: resume of drv:usb dev:1-4 complete after 282.658 msecs
[ 8151.188269] usb 1-5: reset high speed USB device using ehci_hcd and address 3
[ 8151.321437] PM: resume of drv:usb dev:1-5 complete after 241.803 msecs
[ 8151.321696] PM: resume of devices complete after 1222.404 msecs
[ 8151.321975] PM: resume devices took 1.224 seconds
[ 8151.322040] PM: Finishing wakeup.
[ 8151.322044] Restarting tasks ... done.
[ 8162.320195] eth0: no IPv6 routers present

If there's any other terminal output I can post that will be helpful to devs to fix this bug, please let me know.

[hackel (hackel)]

I just upgraded my Dell Mini 9 to 10.04 hoping this issue would go away, but it has not. When I resume from suspend, Network Manager *thinks* that the wireless network I was connected to before suspend is still present, for some reason, and attempts to connect to it. It does this until it times out, at which point then it will (sometimes) connect to the new network. I can switch it manually, and it connects right away. This may be a problem in the BCM4312 driver, however when I run an "iwlist scan" after resuming, the previous network is *not* shown, indicating that the problem resides in Network Manager itself somehow. It's a shame this made it into an LTR, hope it can be fixed soon.

[Andrew Somerville (andy16666)]

Eee PC 1201T: Same complaint. The time to reconnect can vary from twenty seconds to over a minute.

[aysiu (ubuntubugzilla-psychocats)]

Still a problem in Maverick. Takes over thirty seconds to reconnect after resume from suspend.

dmesg | tail
[ 861.369996] sky2 0000:02:00.0: eth0: phy I/O error
[ 861.370083] sky2 0000:02:00.0: eth0: phy I/O error
[ 861.370171] sky2 0000:02:00.0: eth0: phy I/O error
[ 861.370258] sky2 0000:02:00.0: eth0: phy I/O error
[ 861.370345] sky2 0000:02:00.0: eth0: phy I/O error
[ 861.374828] sky2 0000:02:00.0: eth0: enabling interface
[ 861.376178] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 864.147940] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[ 865.152547] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[ 872.192056] eth1: no IPv6 routers present

Also, still seeing this in comments:

cat /usr/lib/pm-utils/sleep.d/55NetworkManager
#!/bin/sh
# If we are running NetworkManager, tell it we are going to sleep.
# TODO: Make NetworkManager smarter about how to handle sleep/resume
# If we are asleep for less time than it takes for TCP to reset a
# connection, and we are assigned the same IP on resume, we should
# not break established connections. Apple can do this, and it is
# rather nifty.

It is nifty. It's been nifty for a while. Any chance it'll get implemented for Natty?

[Mathieu Trudel-Lapierre (cyphermox)]

Seems like this is a new issue rather than the one that was initially reported. It looks like it's really specific to the wl driver too. Could someone still seeing this bug (and using wl, so Broadcom wifi devices) open a separate bug and post the number here so we can track that? I'd like to mark this one closed and focus on the drivers that may still not quite play nicely (and not spam those who already have this fixed for them in the process).

aysiu, I really doubt this has anything to do with what you see. NM can already handle UPower's messages about sleep/resume, it's just that we couldn't get this included in time for Maverick.

[aysiu (ubuntubugzilla-psychocats)]

"Could someone still seeing this bug (and using wl, so Broadcom wifi devices) open a separate bug and post the number here so we can track that?"

It appears someone already has. Here's the link:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/620318

[hackel (hackel)]

Update for Maverick: NM no longer tries to connect to the previous (now non-existent) access point, however instead it seems to wait around 30 seconds until it even tries to connect to anything. This seems intentional. So now we are back to where we started 2 years ago...

[Richard Bailey (bailey937)]

I have a Dell Inspiron Mini 10V and am using the Broadcom STA wifi driver and network manager.

When I suspend my computer (aka sleep, aka suspend to ram) and then wake it up in the same place, I have to wait about 30 seconds for the wifi to reconnect.

I am running 10.10 now. I had the same problem in 10.04 LTS.

I don't remember if the problem occurred in the 9.x release I was running briefly before 10.04 LTS came out.

[Richard Bailey (bailey937)]

I posted to Bug #620318 (which seems to be from other Broadcom users).

The workaround mentioned there (commenting out the lines in /usr/lib/pm-utils/sleep.d/55NetworkManager) works for me.

[aysiu (ubuntubugzilla-psychocats)]

Still happening in Ubuntu 11.04 alpha 2. Let me know if there's any more useful info I can post for diagnosing and fixing the problem before the April release.

[Charlie White (cwhite-curlytops)]

I've been dealing with this for years. Every time network manager gets updated, I have to add this to the beginning of /etc/network/if-pre-up.d/55NetworkManager

exit 0

I put it right after the "nifty" comment about Apple.

[aysiu (ubuntubugzilla-psychocats)]

Charlie, I'm going to try that out. I don't know why we have to keep employing these workarounds.

By the way, this problem is still in Beta 2.

[aysiu (ubuntubugzilla-psychocats)]

Wow! That workaround is great! Thanks, Charlie. It's gone from taking 1:00-1:30 to reconnect to being only about 10 seconds.

[mu3en (mu3en)]

most solutions failed here, however:

changing the last part in /usr/lib/pm-utils/sleep.d/55NetworkManager

from
  thaw|resume)¶
     resume_nm¶

to
  thaw|resume)¶
    resume_nm¶
    sleep 2 && iwlist eth1 scanning &

forces a wifi scan and network manager connects almost immediately after resume.

[aysiu (ubuntubugzilla-psychocats)]

I'm confused by this:

Changed in network-manager:
importance: Unknown → Medium
status: Unknown → New

It's not new. This particular bug report is from 2008. That's almost three years ago. This is old. Three years is six releases in Ubuntu time.

[Jeremy Nickurak (nickurak)]

It's "new" to the upstream bug tracker, bugzilla.gnome.org. Launchpad just
isn't very clear that that's what's happened here.

[ledom (sebastien-domeny)]

#74 solve the problem for me (thinkpad T61)

[Zookalicious (chrishylands)]

Still an issue in Ubuntu 12.04. Using the workaround from #71 or #74 helps the problem a bit, but it stil is quite slow compared to OS X or Windows. This is using the "wl" driver on a Macbook 5,1.

[Matthias Andree (matthias-andree)]

Also affects a wired ATL1E (Atheros wired 1 GBit/s Ethernet) with static IPv4 configuration and IPv6 set to "ignore".
Workaround: "sudo ifconfig eth0 up", or clicking on "LAN" in nm-applet.

[Jeremy Nickurak (nickurak)]

As far as I can tell, I get this issue with a Broadcom BCM4322 wifi card.

--
Jeremy Nickurak -= Email/XMPP: -= <email address hidden> =-

[Thomas Hood (jdthood)]

Compare bug #1017186.

[Mathieu Trudel-Lapierre (cyphermox)]

Like I mentioned above, this is really no longer anything to do with the original bug report; but here it is:

Please try to reproduce the issue (suspend/resume) with a LiveCD of the current development release, Quantal Quetzal. I pushed a patch to wpasupplicant there which should help specifically with drivers such as wl where the first scan request always fails, which is likely the actual problem here.

While testing, obviously don't apply the workarounds suggested here; then report back with whether this solved the issue.

[Bryan Quigley (bryanquigley)]

This bug was marked Incomplete some time ago and was supposed to autoclose after 90 days. I'm going to close it manually due to no activity (and likely the issue has gone away/been fixed).

[brijesh (patelbrijesh333)]

after running sudo service network-manager restart works for me.