|
Bugzilla – Full Text Bug Listing |
| Summary: | NetworkManager 0.8 no longer connects after machine crashed during suspend | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Stefan Seyfried <seife> |
| Component: | Basesystem | Assignee: | Bin Li <bili> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P3 - Medium | CC: | carlosflange, coolo, ctrippe, dimstar, dutchkind, f.alabas, forgotten_--EoyBps8f, forgotten_JoZGrGEMhM, forgotten_vXTZVacoSi, henning.schnoor, hmuelle, jnelson-suse, kkaempf, lmuelle, meissner, msvec, muhlemmer, resler, richard, sebas, suvarchal.kumar, wstephenson, yar, zergling |
| Version: | Factory | Flags: | coolo:
SHIP_STOPPER-
|
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | maint:released:11.3:34885 | ||
| Found By: | Community User | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Deadline: | 2010-08-02 | ||
It was a design decision for NetworkManager that the state survives over reboots. That includes things like wireless enabled/disabled, networking enabled/disabled, etc. The problem here is that for NM, there's no difference between user disabling networking from the applet or the machine going to suspend - there's one API call that both cases use. I agree with the report however, a failed resume should not turn networking off for the following reboot. Maybe we can just remove the calls from pm-utils? Does NetworkManager handle system suspend by itself somehow? If that's not possible, maybe a second, similar interface but "transient", that does not remember the state over a restart, would be in order. It might also be possible to work around this in pm-utils - by checking on boot if the last suspend failed and if it did and we disabled networking during suspend and if it was enabled before, then reenable it again. I assume it would be pretty hard to get reliably right, though. I have the same problem, I had to restore my disk image I created from 11.3 to be able to connect again. Now I tried again, I found no way to restore the network. The button that enables and disables my wireless doesn't work anymore. Very frustrating. I think there should be an option so users can decide if the state of wifi (and bluetooth, in other cases) should be remembered or not. And: how can the network be enabled again? Any fast solutions? After reading this I had a look through the files that had changed and found a way to quickly restore the networkmanager: In the file: /var/lib/NetworkManager/NetworkManager.state change NetworkingEnabled=false into NetworkingEnabled=true and save the file. Run service network restart and the network is back again. I think this "design" is not good and can be a killer, my network is my most important item and I need to be able to switch it on if I want to. I think it should at least respect my wifi button to get it back on as an override. In M7, I sent org.freedesktop.NetworkManager.sleep to NM, then the NM disconnect, from the icon in Notification, right click the icon, from the pop menu, click 'Enable Networking', then the NM works again. So would your guys try it? I am sorry, but I know too little about org.freedesktop so don't know how to issue this command. But when I bring my network back to the disabled state, there is no pop menu when I right click on the knetworkmanager icon, only a greyed out "network disabled" Tell me how to issue this freedesktop command and I will try it. I tried the dbus-send before, and got a message the command was not found, this is an area I am not (yet) knowledgeable about, so please tell how. dbus-send is in /bin/dbus-send in the package "dbus-1", which I'm pretty sure you have installed. The above "dbus_send" is a function in pm-utils which calls "dbus-send", so just replace it with "dbus-send". nm-applet (in package NetworkManager-gnome) has an "enable networking" checkbox, so this is partly a knetworkmanager issue. As much as I hate to say this, but kde network management is dysfunctional since a long time and you simply should be using nm-applet when reporting a bug. bili: I tried sending NM to sleep (without crashing the machine ;) and was able to revive the Network via nm-applet's "enable networking " afterwards. So right now this is mostly a KDE-only bug. In the NM Plasmoid, there's an enable networking bug, I just don't know yet which one we'll be shipping in 11.3. So this "might" be fixed. :-) Although knetworkmanager maybe buggy but I use it since 11.2 without problems, actually quite stable. Connecting to wep encrypted networks was a thing I had to discover, but that goes without any problems now. But sure, this "enable networks" should be part of it. But still I think the nm should honor the hardware switches I have on my laptop. Pressing them when the network was disabled did nothing, I would expect the network to come on and the led illuminated when I press it, no matter what. So that would still be an improvement. I managed to use "dbus-send", that works and enables the network again as normal user. Thanks. Do you have the same issue when using the Plasmoid? Or does it "just work" there? If you refer to the use of knetworkmanager in 11.2, that doesn't have this issue, it just works. It has other issues that fall outside the scope of this bug report. Will, Would mind look at it? Bin Li, While it's true that knetworkmanager needs an 'enable networking' action, this bug is about the daemon not clearing its 'sleep' state on normal boot after a failed suspend, and using a client to manually wake networkmanager is a workaround. Consider the case where you turn on a machine, not knowing that its last suspend failed, and NM is asleep until someone logs in and wakes it - no networking, not even system connections. As per comment #2 and #5, NM should check if the startup follows a failed suspend and clear any persisted state. Back to you :) 597572 may be a dupe of this bug, but crrodriguez and adrian seem to experience this as a random race. I can't reproduce it without the suspend crash though. I have the same problem on my laptop. To comment 4: The easiest way to manage network from console seems to be cnetworkmanager. The command enabling network at all is "cnetworkmanager -o true". But it is only a workaround and not the solution of the problem. I don't have a good idea for this issue, so I reported it in bgo, so let focus on it now, it should be a features. https://bugzilla.gnome.org/show_bug.cgi?id=622362 I was just hit by that again, this is really a bad issue, you can't find a solution for it without accessing the net and even though yast allows switching to ifupdown it might just be too much for the average user, why not just add
dbus_send --system \
--dest=org.freedesktop.NetworkManager \
--print-reply --reply-timeout=200 \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.wake
to the networkmanager starting script?
I know this will affect everybody who needs the functionality, but most will use a rfkill switch anyway eh?
There is currently no sane way for users to recover network after a failed suspend/hibernate!
Hm after hitting the bug again, I just tried a new suspend / resume cycle after nm wouldn't come up after a previous crash and oh wonder he ignored the wake status, due to calling .wake on resume as Stefan already explainedm, so there is an example we already ignore it on one point, let's just ditch the incomplete feature for now and just call .wake on system start as well. sounds like a good work around to me. but I think releasing this as update would do, so I mark it as !ship_stopper Hi, Dan did some work about a month ago to split that up and add a real enable/disable networking toggle. http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8_1&id=ee3ece9dac985034c5c1f81a6769b40fd7856579 and http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8_1&id=30374453b4b12953ed5a9b7bec4b81fe263ae9db I'll try to merge the patch in 0.8, maybe these would be helpful. *** Bug 618704 has been marked as a duplicate of this bug. *** ignore my last comment I've got the wrong bug. Sorry I found a very similar problem with 11.3 rc2 as well. I have a Compaq CQ60 laptop with built in wireless, bluetooth and wired ethernet port. on a second or third reboot after loading 11.2 the ethernet connection was not up and running. My daft solution was to disconnect the cable and reconnect after 5 seconds. Network Manager then connected within 1 or 2 seconds (tried this three times to ensure this was not a fluke (ie reboot - disconnect - reconnect - good result). My assumption is that reconnecting the cable made this form of network access priority over the wireless. I followed David Kerkhof's suggestion above (#5) and rebooted and the ethernet connection was immediately available. However, the issue with this as a solution is that right-clicking on NM in the tray shows "enable wireless" as ticked (on). The trouble is that if I do decide to use the wireless function, will I remember to re-set the suggestion David made? Answer- NO!. (In reply to comment #25) > I found a very similar problem with 11.3 rc2 as well. I have a Compaq CQ60 > laptop with built in wireless, bluetooth and wired ethernet port. > > on a second or third reboot after loading 11.2 the ethernet connection was not > up and running. My daft solution was to disconnect the cable and reconnect > after 5 seconds. Network Manager then connected within 1 or 2 seconds (tried > this three times to ensure this was not a fluke (ie reboot - disconnect - > reconnect - good result). My assumption is that reconnecting the cable made > this form of network access priority over the wireless. > > I followed David Kerkhof's suggestion above (#5) and rebooted and the ethernet > connection was immediately available. However, the issue with this as a > solution is that right-clicking on NM in the tray shows "enable wireless" as > ticked (on). The trouble is that if I do decide to use the wireless function, > will I remember to re-set the suggestion David made? Answer- NO!. UPDATE. 5 July Following this comment I rebooted today and the problem is still evident. When checking NetworkManager.state, all three lines are set to =true. Hope this helps. I'm just writing the patch for it now. I'll submit it tomorrow. Done. You can test the packages from below. https://build.opensuse.org/package/binaries?package=NetworkManager&project=home%3ABinLi%3Abranches%3AGNOME%3AFactory&repository=openSUSE_Factory https://build.opensuse.org/package/binaries?package=NetworkManager-gnome&project=home%3ABinLi%3Abranches%3AGNOME%3AFactory&repository=openSUSE_Factory -Fixed.
42705 State:new By:BinLi When:2010-07-07T18:02:23
submit: home:BinLi:branches:GNOME:Factory/NetworkManager-gnome -> GNOME:Factory
Descr: make networking enable/disable knob distinct from
sleep/wake(bnc#585433,bgo#622362).
42704 State:new By:BinLi When:2010-07-07T18:01:59
submit: home:BinLi:branches:GNOME:Factory/NetworkManager -> GNOME:Factory
Descr: make networking enable/disable knob distinct from
sleep/wake(bnc#585433,bgo#622362).
*** Bug 597572 has been marked as a duplicate of this bug. *** would be useful for 11.3 customers I guess. +1 Considering that it was already reported 3 times, I think it's important to do the update, +1. Can we wait with this while I make the same change to knetworkmanager? See also bug 552862 Hello guys, The same story here. I did not know of this bug being real, or was it just me. But now I see this report, I know why Because I did not get the Knetworkmanager to work, I seletected "use traditional method with Ifup" in yast and saved it. After that open yast again to set my wireless. Everything looked ok, he found the network configured the standard list. But when done, still no network. I did it manualy now using iwconfig and ifconfig. Now, after reboot I see that YaST has switched itself back to the NetworkManager option. Isn't that odd? Shall I post a new bug report on that one, or you think it will also be solved with this fix? I mean, NetworkManager is user controlled, YaST is root controlled, so it should never be possible NetworkManager destroys YaST configuration. Tim, Separate another bug for your issue would be better. Will, Do you finish the knetworkmanager? We just wait for the swampid. Li Bin, I'm still working on other fixes in KNM i want to ship (see 2 comments up), please proceed with your update. I was faced with this issue after a suspend/ resume crash too. Nice bug. :/ Maintenance, Do we need let it into updates? The SWAMPID for this issue is 34865. This issue was rated as critical. Please submit fixed packages until 2010-08-02. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/34865 Update process started; be so kind and submit a patchinfo I have the same problem but not after hibernation, but even when the computer starts. After a new installation of SUSE 11.3, NetworkManager does not work. It can be activated with the command: :~>solid-network set networking enabled Dawid, Your problem was caused by the knetworkmanager. It was already in another separate bug for it. Done. The request id is 44345.
44345 State:new By:BinLi When:2010-08-02T10:49:46
submit: home:BinLi:branches:openSUSE:11.3:Update:Test/NetworkManager -> openSUSE:11.3:Update:Test
Descr: Add NetworkManager-network-enable-disable.patch, make networking
enable/disable knob distinct from sleep/wake
(bnc#585433,bgo#622362, swampid#34865).
Update released for: NetworkManager, NetworkManager-debuginfo, NetworkManager-debugsource, NetworkManager-devel, NetworkManager-doc, NetworkManager-glib, NetworkManager-glib-debuginfo Products: openSUSE 11.3 (debug, i586, x86_64) So it happened to me again today, after the update. bash$ rpm -qa|grep NetworkManager NetworkManager-0.8-8.1.1.x86_64 NetworkManager-glib-0.8-8.1.1.x86_64 NetworkManager-kde4-0.9.svn1057339-4.1.x86_64 NetworkManager-kde4-libs-0.9.svn1057339-4.1.x86_64 NetworkManager-openvpn-0.8-3.1.x86_64 NetworkManager-openvpn-kde4-0.9.svn1057339-4.1.x86_64 NetworkManager-pptp-0.8-3.1.x86_64 NetworkManager-pptp-kde4-0.9.svn1057339-4.1.x86_64 NetworkManager-vpnc-0.8-3.1.x86_64 NetworkManager-vpnc-kde4-0.9.svn1057339-4.1.x86_64 Not sure if it is exactly the same issue, because the above wake command reported that NM is already awake, but I was not able to get NM to have link on eth0 (ifconfig/dhcpcd worked of course), even in console. Is it a same bug or something different? Michal, I'm not sure what's your exact issue of you, this issue is when you send a dbus org.freedesktop.NetworkManager.sleep, the NM will go to sleep, the /var/lib/NetworkManager/NetworkManager.state wouldn't be changed. When you dissable Networking or wireless, the file will be changed. If any issue separate another bug would be better. Have a look at this: bash# cat /var/lib/NetworkManager/NetworkManager.state [main] NetworkingEnabled=false WirelessEnabled=true WWANEnabled=true bash# dbus-send --system --dest=org.freedesktop.NetworkManager \ --print-reply --reply-timeout=200 /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.wake Error org.freedesktop.NetworkManager.AlreadyAsleepOrAwake: Already awake bash# cat /var/lib/NetworkManager/NetworkManager.state [main] NetworkingEnabled=false WirelessEnabled=true WWANEnabled=true Michal,you may check Bug 623409 . Michal, It's fine, the wake/sleep don't change the state, you just need enable your Network in nm-applet. knetworkmanager has no such option to "enable network". Changing NetworkingEnabled to true helped and now everything works fine. I still think it's a bug, it happened after crashed suspend and NM was left in NetworkingEnabled=false state. But I will wait if it happens again and will report it as a new bug then. Please view bnc #619934 for your issue, it's another issue. Thanks. *** Bug 552862 has been marked as a duplicate of this bug. *** *** Bug 631491 has been marked as a duplicate of this bug. *** Hi, I have another issue which may or may not be related to this bug. Whenever I boot openSUSE 11.3 (fresh install of the released version), networking is disabled. The knetworkmanager applet says that network management is disabled. With a "service network restart", networking starts. The trick from comment 47, to use "solid-network set networking enabled" does not help. On the next reboot, networking is disabled again. This happens on a laptop which is connected to wired ethernet (although a wireless card is installed as well). The bug appeared directly after installing openSUSE 11.3, and still occurs after installing the available updates. I'm not sure if this is the same bug as the one discussed here, maybe it's a seperate issue. Thanks, Henning Hi, Make sure if the you use the NetworkManager in YaST first, after that check the NetworkManager process was running. after that we can distinct where the bug from, the knetworkmanager or NetworkManager. Please separate another bug for it. Hi Bin, I started a new bug on the topic, see bug 635613. Thanks, Henning This is an autogenerated message for OBS integration: This bug (585433) was mentioned in https://build.opensuse.org/request/show/44345 11.3:Test / NetworkManager |
If a machine crashes during a suspend to disk/ram, after next boot NetworkManager 0.8 will no longer connect to any network (wired or wireless), the applet will always show "networking system disabled". I tracked it down to the fact, that NM since 0.8 apparently remembers the "suspended" setting over a restart / reboot. During suspend, pm-utils calls dbus-send --system \ --print-reply --reply-timeout=200 \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.sleep During resume, it wakes up NM by calling dbus_send --system \ --dest=org.freedesktop.NetworkManager \ --print-reply --reply-timeout=200 \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.wake If the machine crashes during suspend, the .wake is not called and NM remains suspended forever. No matter if it those pm-utils calls are stupid or not, IMHO NetworkManager should not remember this setting via a restart or even a reboot of the machine. (adding people to CC who will probably have to deal with fallout from this bug, because it might get attributed to suspend or wireless).