connect takes long time after resuming from suspend

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in network-manager.
Additionally, it would be helpful if you could submit some log files after experiencing the crash - '/var/log/messages' and '/var/log/daemon.log' would be quite useful.

Sorry, I was not sure if it is a kernel or NetworkManager bug...

Interesting part of /var/log/messages (though not spectacular...):
Sep 19 09:27:31 idefix kernel: [17626.364000] Stopping tasks ... done.
Sep 19 09:27:31 idefix kernel: [17627.584000] Suspending console(s)
Sep 19 09:27:31 idefix kernel: [17627.604000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Sep 19 09:27:31 idefix kernel: [17627.632000] sd 0:0:0:0: [sda] Stopping disk
Sep 19 09:27:31 idefix gnome-power-manager: (jhs) Rechner wird aufgeweckt
Sep 19 09:27:31 idefix kernel: [17630.468000] ACPI: PCI interrupt for device 0000:00:1f.1 disabled
Sep 19 09:27:31 idefix kernel: [17630.468000] ACPI: PCI interrupt for device 0000:00:1e.2 disabled
Sep 19 09:27:31 idefix kernel: [17630.468000] ACPI: PCI interrupt for device 0000:00:1d.7 disabled
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: PCI interrupt for device 0000:00:1d.3 disabled
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: PCI interrupt for device 0000:00:1d.2 disabled
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: PCI interrupt for device 0000:00:1d.1 disabled
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: Transitioning device [C256] to D0
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: Transitioning device [C256] to D0
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: Transitioning device [C255] to D0
Sep 19 09:27:31 idefix kernel: [17630.484000] ACPI: Transitioning device [C255] to D0
Sep 19 09:27:31 idefix kernel: [17630.484000] PCI: Enabled ICH6/i801 SMBus device
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C255] to D3
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C255] to D3
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C256] to D3
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C256] to D3
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C257] to D3
Sep 19 09:27:31 idefix kernel: [17630.544000] ACPI: Transitioning device [C257] to D3
Sep 19 09:27:31 idefix kernel: [17630.572000] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 21
Sep 19 09:27:31 idefix kernel: [17630.572000] PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
Sep 19 09:27:31 idefix kernel: [17630.572000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 18
Sep 19 09:27:31 idefix kernel: [17630.572000] usb usb2: root hub lost power or was reset
Sep 19 09:27:31 idefix kernel: [17630.572000] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
Sep 19 09:27:31 idefix kernel: [17630.572000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 19
Sep 19 09:27:31 idefix kernel: [17630.572000] usb usb3: root hub lost power or was reset
Sep 19 09:27:31 idefix kernel: [17630.572000] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
Sep 19 09:27:31 idefix kernel: [17630.572000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
Sep 19 09:27:31 idefix kernel: [17630.572000] usb usb4: root hub lost power or was reset
Sep 19 09:27:31 idefix kernel: [17630.57...

yet another wpasupplicant related timeout issue. The crash on nm side is bad, but we should definitly try to figure out as well, why we get those timeouts.

network-manager shouldn't crash in any case. ONce i find a way to reproduce I can probably fix it :).

This looks like another manifestation of bug #139966 "NetworkManager fails at startup: waitpid () from /lib/libpthread.so.0"

we already have enough duplicates of network manager crashes tracked in bug 141233 .... lets use this bug for the "takes ages to connect" bug mentioned by initial reporter.

First, let me be a bit more specific about the "takes ages to connect thing":
In Feisty, nm reconnect that fast that usually after I typed in my password to unlock the screen it had reconnected.
In Gutsy, more than half of the time, the network manager displays a "connected" icon after resume though it is not connected and otherwise it displays a "not connected" icon for ~15 seconds and start to reconnect after that time. Sometimes (read too often) it should crashes and I have to restart nm manually.

After todays update, I had the problem that nm would instantly crash when trying to connect to a wireless with a saved password in keyring manager. Deleting the key and trying some restart eventually solved this but it is really not as nice as it was in feisty.

Please tell me if I can help you with this bug by installing debugging symbols, using gdb, doing other weird things, etc.

can you please upgrade to the latest network-manager (...ubuntu13), then test if you still see the delay.

Then, please test the wpasupplicant testpackage from my ppa: http://ppa.launchpad.net/asac/ubuntu/pool/main/w/wpasupplicant/

and let me know if it helps.

In anycase, please capture your /var/log/syslog and daemon.log before _and_ after upgrading network manager/wpasupplicant and afterwards. Then attach both logs please.

Thanks for your contribution,

 - Alexander

sorry .. i meant in case i want the logs from before and after installing the new wpasupplicant package. If you want attach the log from before upgrading network-manager as well ... but that is not essential.

Thanks,

 - Alexander

wpasupplicant (0.6.0+0.5.8-0ubuntu1) gutsy; urgency=low

  * New upstream release
  * remove patch 11_erroneous_manpage_ref, applied upstream
  * remove patch 25_wpas_dbus_unregister_iface_fix, applied upstream

  [ Alexander Sack ]
  * bumping upstream version to replace development version 0.6.0 with
    this package from stable release branch.
  * attempt to fix wierd timeout and high latency issues by going
    back to stable upstream version (0.5.9) (LP: #140763,
    LP: #141233).

 -- Reinhard Tartler <email address hidden> Sun, 26 Aug 2007 16:06:57 +0200

Sorry, I cannot try your wpa_supplicant packages because gDebi claims they are older then my installed and I do not want to break the system.

The crashes seem to have disappeared after the latest updates but reconnection is still slower than it was in feisty. I have attached /var/log/messages and /var/log/daemon.log of the current installation and I hope they are useful.

Thanks,
Johannes

Sorry, the perviously attached log was deamon.log...

i need your /var/log/syslog then.

Hmm, after some new updates, it crashes again now 50% of the time. Syslog after wake-up is attached!

It seems now fixed which the latest updates. I cannot say what fixed it exactly but it works good and fast now - Thanks for your effort!

please test the package mentioned in: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/145683/comments/15

Thanks,
 - Alexander

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the drop down box. You can learn more about bug statuses at http://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Feel free to submit any future bugs you may find.