Network Manager sometimes needs to be restarted when coming back from Standby/Hibernation

[takeda64]

I'm Using fairly recent (at most 2 days old) Ubuntu Intrepid.

Sometimes when computer is going back from standby or hibernation, the network manager doesn't seem to try to connect to wireless network.

Trying
sudo iwlist scan

doesn't work, it says (I'm citing it from memory) that the wlan0 device cannot be scanned.

To fix it I have to type:
sudo /etc/init.d/NetworkManager restart

Wouldn't be better to set up Ubuntu so it would call /etc/init.d/NetworkManager stop before performing Suspend/Hibernation, and then when coming back calling /etc/init.d/NetworkManager start?

Or perhaps that's already done?

I'm not sure if I should report it separately, but also NetworkManagers also tend to forget that there was no "Enable networking" checkmark before Suspend/Hibernation.

[FredBezies (fredbezies-deactivatedaccount)]

Moving to right component in order to get it triaged. But it smells like a duplicate of a known bug.

Can you provide more technical info : just type in a terminal :

lspci -vvnn > lspci.log

Thanks.

[takeda64 (takeda64)]

I'm sorry I didn't attach this, it felt to me like it is something that is not laptop specific.
Here's my hardware list.

[takeda64 (takeda64)]

I run this from sudo, it should provide more details (not sure how they're useful)

[Alexander Sack (asac)]

when this happens, could you check whether NetworkManager and nm-applet process is still running?

[takeda64 (takeda64)]

It does, I see its icon, in the top bar.

One thing. To save battery, I often disable networking, in the NetworkManager, and then switch the power off.
I noticed that when I'm coming back from standby, NetworkManager seems to always have network enabled.

Is it possible, that the checkmark doesn't accurately display the actual network state?

[Alexander Sack (asac)]

On Mon, Oct 27, 2008 at 01:09:11AM -0000, Derek Kulinski wrote:
> It does, I see its icon, in the top bar.
>
> One thing. To save battery, I often disable networking, in the NetworkManager, and then switch the power off.
> I noticed that when I'm coming back from standby, NetworkManager seems to always have network enabled.
>
> Is it possible, that the checkmark doesn't accurately display the actual
> network state?
>

Yes, that might be true. Does unchecking and checking again help?

 - Alexander

[takeda64 (takeda64)]

Ok, my initial assumption, that it might be due to me disabling networking before hibernating/standby is incorrect. I tested it both ways, and the behavior is random, and not dependent on previous state.

So there are two parts of the bug:
- minnor annoyance, that the networking is always enabled when coming back from standby
- that driver needs to be restarted sometimes

When second problem happens, restarting NetworkManager or unchecking/checking "Enable Wireless" fixes it.

This potentially might be also a kernel issue, perhaps the driver is not always restarted?

In Bug #276990 I noted that today when this problem happened, and I tried to toggle off/on "Enable Wireless" it crashed the system. It might or might not be connected together.

P.S. Sorry for delay, but I needed some time to get more details abut the bug.

[svasie (svasie)]

Can it be a dupplicate of 274405?

[Alexander Sack (asac)]

On Thu, Oct 30, 2008 at 06:42:28AM -0000, Derek Kulinski wrote:
> Ok, my initial assumption, that it might be due to me disabling
> networking before hibernating/standby is incorrect. I tested it both
> ways, and the behavior is random, and not dependent on previous state.
>
> So there are two parts of the bug:
> - minnor annoyance, that the networking is always enabled when
> coming back from standby

do you mean it will come back after standby in a different state
(e.g. before networking disabled/unchecked, after enabled/checked)?

> - that driver needs to be restarted sometimes

if the driver needs to be reloaded (if thats what you mean with
restarting) its probably a driver bug. However, reloading might also
trigger something in NM (like restarting the supplicant).

>
> When second problem happens, restarting NetworkManager or
> unchecking/checking "Enable Wireless" fixes it.

could you instead of doing that simply run:

  sudo killall wpasupplicant

and see if that has the same curing effect?

 - Alexander

[takeda64 (takeda64)]

It possibly could be duplicate, since the end result is the same (I didn't wait for one minute though, but if this happens again I will try to).

There's one thing that doesn't match that bug report (it might be a separate issue).

When this happened today I saw this in logs:
Oct 30 17:09:52 tkdlap2 NetworkManager: <info> (wlan0): preparing device.
Oct 30 17:09:52 tkdlap2 NetworkManager: <info> (wlan0): deactivating device (reason: 2).
Oct 30 17:09:52 tkdlap2 NetworkManager: <WARN> nm_device_wifi_set_ssid(): error setting SSID to '(null)' for device wlan0: Resource temporarily unavailable
Oct 30 17:09:52 tkdlap2 NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Oct 30 17:09:52 tkdlap2 NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Oct 30 17:09:52 tkdlap2 kernel: [ 276.892815] ------------[ cut here ]------------
Oct 30 17:09:52 tkdlap2 kernel: [ 276.892833] WARNING: at /build/buildd/linux-backports-modules-2.6.27-2.6.27/debian/build/build-generic/compat-wireless-2.6/net/mac80211/main.c:232 ieee80211_hw_config+0x85/0x90 [lbm_cw_mac80211]()
Oct 30 17:09:52 tkdlap2 kernel: [ 276.892842] Modules linked in: tun ipv6 af_packet i915 drm binfmt_misc rfcomm sco bridge stp bnep l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_ondemand freq_table wmi container pci_slot sbs sbshc iptable_filter ip_tables x_tables panasonic_acpi parport_pc lp parport loop joydev pcmcia snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm arc4 ecb crypto_blkcipher snd_seq_dummy pcspkr evdev snd_seq_oss snd_seq_midi snd_rawmidi iwlagn video serio_raw snd_seq_midi_event output tpm_infineon tpm tpm_bios iwlcore rfkill psmouse snd_seq led_class snd_timer snd_seq_device lbm_cw_mac80211 snd yenta_socket lbm_cw_cfg80211 rsrc_nonstatic sdhci_pci sdhci pcmcia_core mmc_core ac battery button soundcore iTCO_wdt iTCO_vendor_support snd_page_alloc intel_agp agpgart shpchp pci_hotplug ext3 jbd mbcache sd_mod crc_t10dif sg ata_piix pata_acpi ata_generic ahci libata scsi_mod dock sky2 ehci_hcd uhci_hcd usbcore thermal processor fan
Oct 30 17:09:52 tkdlap2 kernel: bcon tileblit font bitblit softcursor fuse
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893059] Pid: 6069, comm: NetworkManager Tainted: G W 2.6.27-7-generic #1
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893067] [<c037c406>] ? printk+0x1d/0x1f
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893081] [<c0131de9>] warn_on_slowpath+0x59/0x90
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893096] [<c030d400>] ? nlmsg_notify+0x30/0x90
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893108] [<f916335d>] ? inet6_ifinfo_notify+0x7d/0xd0 [ipv6]
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893146] [<f91635e8>] ? addrconf_notify+0x238/0x3d0 [ipv6]
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893182] [<f8c0acce>] ? iwl_radio_kill_sw_enable_radio+0xe/0x140 [iwlcore]
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893206] [<c012a18b>] ? __cond_resched+0x1b/0x40
Oct 30 17:09:52 tkdlap2 kernel: [ 276.893216] [<c037cdf5>] ? _cond_resched+0x35/0x50
Oct 30 17:09:52 tkdlap2 kernel: [ 27...

[Alexander Sack (asac)]

On Fri, Oct 31, 2008 at 02:55:37AM -0000, Derek Kulinski wrote:
> It possibly could be duplicate, since the end result is the same (I
> didn't wait for one minute though, but if this happens again I will try
> to).
>
> There's one thing that doesn't match that bug report (it might be a
> separate issue).

this bug you see here (with all the call traces) is bug 291291

 - Alexander

[takeda64 (takeda64)]

Hello Alexander,

Thursday, October 30, 2008, 1:53:42 PM, you wrote:

> do you mean it will come back after standby in a different state
> (e.g. before networking disabled/unchecked, after enabled/checked)?

yes, generally it's always enabled.

>> - that driver needs to be restarted sometimes
> if the driver needs to be reloaded (if thats what you mean with
> restarting) its probably a driver bug. However, reloading might also
> trigger something in NM (like restarting the supplicant).

Yeah, I guess you might be right. What threw me off is that often when
I'm disabling wireless network the system is frozen for about 2
seconds, so I though NM might be unloading driver or doing something
like that.

>> When second problem happens, restarting NetworkManager or
>> unchecking/checking "Enable Wireless" fixes it.
> could you instead of doing that simply run:
> sudo killall wpasupplicant
> and see if that has the same curing effect?

I'll try that next time, though I doubt it might help. When the
problem happens I don't see any wireless network and iwlist scan
doesn't return anything.
I think wpasupplicant is only necessary when accessing WPA networks.
--
Best regards,
 Derek mailto:<email address hidden>

Radioactive cats have 18 half-lives.

[Alexander Sack (asac)]

On Fri, Oct 31, 2008 at 03:40:06PM -0000, Derek Kulinski wrote:
> >> When second problem happens, restarting NetworkManager or
> >> unchecking/checking "Enable Wireless" fixes it.
> > could you instead of doing that simply run:
> > sudo killall wpasupplicant
> > and see if that has the same curing effect?
>
> I'll try that next time, though I doubt it might help. When the
> problem happens I don't see any wireless network and iwlist scan
> doesn't return anything.
> I think wpasupplicant is only necessary when accessing WPA networks.

wpasupplicant is used for everything wireless nowadays. Please test
thoroughly (and multiple times), as the outcome of that test would
define what to do next.

 - Alexander

[takeda64 (takeda64)]

Ok, it seems that killing wpa_supplicant does the job.

Though, I noticed, that NM while most of the time after coming back from standby has the network enabled I saw at least once that it was disabled while I'm pretty sure it was enabled before standby.

[takeda64 (takeda64)]

restarting wpa_supplicant works pretty much always, though I had once to unload and load again the iwlagn and iwlcore to make WiFi work. Right now it's a minor annoyance to me, but this is something that can make Ubuntu less attractive to new users.

[Alexander Sack (asac)]

On Fri, Dec 12, 2008 at 10:55:46PM -0000, Derek Kulinski wrote:
> restarting wpa_supplicant works pretty much always, though I had once to
> unload and load again the iwlagn and iwlcore to make WiFi work. Right
> now it's a minor annoyance to me, but this is something that can make
> Ubuntu less attractive to new users.
>
I think its a combination of NM using the same state for "sleeping"
when you disable networking and when you go to suspend. The other part
is probably on driver and even wpasupplicant side .... sounds hard to
tell for sure based on your description. Adding both targets
accordingly.

 affects ubuntu/wpasupplicant
 affects ubuntu/linux

 - Alexander

[Alexander Sack (asac)]

Derek Kulinski wrote:
> restarting wpa_supplicant works pretty much always, though I had once to
> unload and load again the iwlagn and iwlcore to make WiFi work. Right
> now it's a minor annoyance to me, but this is something that can make
> Ubuntu less attractive to new users.
>
>
restarting like "sudo killall wpa_supplicant" ?

[takeda64 (takeda64)]

Hello Alexander,

Monday, December 22, 2008, 8:42:15 AM, you wrote:

> restarting like "sudo killall wpa_supplicant" ?

Yes, since you recommended to do killall wpa_supplicant I was doing
it, and it always worked except one instance, in which unloading and
loading the driver helped.

When computer wakes up, those are typical commands I give to it:

$ sudo iwlist scan
when it fails, and it often does - e.g. it returns right away that
there's no results, I do:
$ sudo killall wpa_supplicant
$ sudo iwlist scan
and after that getting connected.

--
Best regards,
 Derek mailto:<email address hidden>
CCNA, SCSA, SCNA, LPIC, MCP certified

The beginning of the programmer's wisdom is understanding the difference between getting program to run and having a runnable program

[takeda64 (takeda64)]

interestingly, this doesn't seem to happen (or happens less often)
when I use my WiFi at home...

The difference between mine and other networks (mainly in school) is
that at home is only one access point (one SSID and one AP).
In school I have few SSID, though most of the times only one is
available. Though that SSID has multiple access points, I also
generally open laptop at different location than when I closed it.
Beacon frames are being sent less frequently (at least I belive so) at
school's network.

Though, that sudo iwlist scan in that situation often returns with no
results without even thinking (scanning) is not correct. I often run
it several times before I call sudo killall wpa_supplicant.

[Alexander Sack (asac)]

Derek Kulinski wrote:
>
> $ sudo killall wpa_supplicant
> $ sudo iwlist scan
> and after that getting connected.
>
>
the explicit scans shouldnt be needed i think.

[takeda64 (takeda64)]

> the explicit scans shouldnt be needed i think.

I might be impatient... (when I open laptop I generally want to access
the Internet right away).
What's the reasonable amount of time it should normally take to start?

[Alexander Sack (asac)]

On Wed, Dec 24, 2008 at 12:19:34AM -0000, Derek Kulinski wrote:
> > the explicit scans shouldnt be needed i think.
>
> I might be impatient... (when I open laptop I generally want to access
> the Internet right away).
> What's the reasonable amount of time it should normally take to start?
>

not really sure, but after resume and after things have settled and
then killing wpa_supplicant should make it trigger connection within a
few seconds.

 - Alexander

[takeda64 (takeda64)]

Hello Alexander,

> not really sure, but after resume and after things have settled and
> then killing wpa_supplicant should make it trigger connection within a
> few seconds.

No, no... after doing that (killing wpa_supplicant) it pretty much
always works. I just think that this shouldn't be necessary. For
people who're just trying Linux for their first time, it might be
extremely confusing.

P.S. I';m not sure if I respond to the other question, but when I'm
starting laptop from the same place (home - the access point is
actually FreeBSD 7.0 computer) this doesn't seem to happen (or at
least I don't remember needing to do it). In school (multiple access
points, this happens often enough to be pretty annoying.

--
Best regards,
 Derek mailto:<email address hidden>

What happens if you get scared half to death twice?

[Martin-Éric Racine (q-funk)]

I experience this issue on Intrepid also and pretty much at random. Force-reloading NM usually fixes it.

Btw, why is this bus still marked as incomplete? From the looks of it, everyone provided all the extra info that was requested.

[Alexander Sack (asac)]

so far i understand that killing wpa_supplicant after restart helps. So for now I assume that NM sends a dbus signal for scan before wpasupplicant is ready. Will set NM and wpasupp to triaged until we found where to fix this best.

Maybe you could also try the latest intrepid bits in the network manager PPA? (https://edge.launchpad.net/~network-manager/+archive). Thanks.

[Alexander Sack (asac)]

On Tue, Dec 30, 2008 at 03:06:01AM -0000, Derek Kulinski wrote:
> Hello Alexander,
>
> > not really sure, but after resume and after things have settled and
> > then killing wpa_supplicant should make it trigger connection within a
> > few seconds.
>
> No, no... after doing that (killing wpa_supplicant) it pretty much
> always works. I just think that this shouldn't be necessary. For
> people who're just trying Linux for their first time, it might be
> extremely confusing.

Yes, its like i said. either NM has a race and doesnt properly send a
"Scan" to wpasupplicant after wake up (e.g. too early) ... or
wpasupplicant has a race and forgets about the scan because when it
receives it something isnt ready yet.

Can you check out the network-manager for intrepid available in
http://launchpad.net/~network-manager/+archive? If that fixes it, it
was definitly an NM issue :)

 - Alexander

[Henrik (neu242)]

This bug affects me as well. I run Karmic, and I have never been able to resume from standby because of bug #290019. That's fixed for me now, and I see now that I need to restart NetworkManager after I wake up from standby.

A plain "sudo /etc/init.d/NetworkManager restart" does not work. I have to "sudo killall NetworkManager && /etc/init.d/NetworkManager start".

Versions:
network-manager 0.8~a~git.20090804t185522.4bab334-0ubuntu1
linux-image-2.6.31.5-generic 2.6.31-5.24
pm-utils 1.2.5-2ubuntu4

[Leann Ogasawara (leannogasawara)]

I'm not yet convinced this is a kernel issue so am setting the linux kernel task to Incomplete for now until it's proven this is driver related.

[Henrik (neu242)]

I still have to restart NetworkManager after resuming from suspend, with the latest karmic installed.

Issuing a "sudo restart network-manager" is sufficient.

[Henrik (neu242)]

This bug is solved, as mentioned in bug #529424

[Jeremy Foshee (jeremyfoshee)]

takeda64,
    Can you verify the statement by neu above?

Thanks!

~JFo

[leo.sutton (leo-sutton)]

I think I too suffer from this, and that it has not been solved, when I resume from suspend I cannot see any wireless networks in the applet, and un-ticking then ticking 'Enable Networking' doesn't seem to help. Also, when I run sudo /etc/init.d/NetworkManager restart, I get the message sudo: /etc/init.d/NetworkManager: command not found.

[papukaija (papukaija)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 524454, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.