GNOME Bugzilla – Bug 346615
Network disable/enable not remembered after suspend
Last modified: 2010-06-26 17:57:13 UTC
NetworkManager always enables the network after a suspend, even if it was explicitly disabled before the suspend: 1. Disable the network from the menu 2. Suspend your laptop 3. Wake up some time later (next train, in my case) Expected: 4. Still a disabled network Actual: 4. NM start scanning for wlan access points and connects to the train station's AP, eating my precious laptop battery power!
Oh, this is NM 0.6.3
Is this related to #353431 ?
No, they aren't related. This seems to be a bug. Basically, when you click the option in the applet, it sends the "sleep" or "wake" signals to the daemon. The same happens when you suspend/resume...
This is still an issue with the 0.7 SVN snapshot used in Ubuntu Intrepid.
*** Bug 560143 has been marked as a duplicate of this bug. ***
This bug does not affect me anymore. Can anybody else confirm ?
It still should be a problem if your suspend/resume support is properly working. suspending via pm-utils tells NM to sleep, resuming tells NM to wake up. So we're really overloading the sleep state here with both suspend/resume and networking enabled functionality. You might check whether your pm-utils hooks (/usr/lib64/pm-utils/sleep.d/55NetworkManager or /usr/lib for 32-bit) use --print-reply in the dbus-send calls, which is necessary for proper suspend/resume support. If they aren't there's a well-known dbus bug that looses the D-Bus message from dbus-send if dbus-send exits too quickly, causing NM to never get the sleep/wake messages. But fixing that will bring back your problem of the enabled state getting reverted on resume.
I can easily reproduce this in NetworkManager Applet 0.7.998, Ubuntu 10.4 Alpha 2+. My /usr/lib64/pm-utils/sleep.d/55NetworkManager script does use --print-reply.
(In reply to comment #8) > I can easily reproduce this in NetworkManager Applet 0.7.998, Ubuntu 10.4 Alpha > 2+. > > My /usr/lib64/pm-utils/sleep.d/55NetworkManager script does use --print-reply. Ah, right. So the problem is that right now suspend/resume *is* Networking Enabled; that's what the pm-utils scripts poke. It's a fairly large fix internally to add /another/ device block and make sure that the logic is correct for all the state changes. So I think the behavior here is expected, but is obviously a bug. It's been this way since 0.6 so it's not a really regression, but does need to get fixed because it's annoying.
In NM 0.8, disabling the wireless network is not persistent after a boot. I would expect that settings are kept between reboots.
(In reply to comment #10) > In NM 0.8, disabling the wireless network is not persistent after a boot. > I would expect that settings are kept between reboots. Yeah, though that's a different bug than this one.
5ca1a9d546be81b54e57d525b54ff92597de6115 (0.7.x) ee3ece9dac985034c5c1f81a6769b40fd7856579 (0.8.1) fa70542c618665cf203a2b71fa0e504f759f7902 (master)
Applet commits: 7f247224c41754b8e76f0efb7e3cb593d7926ad8 (0.7.x) f9a9bfc4d63a138ac81ee4f6d84b3d5d87bff250 (0.8.1) adf56461a7859280f8ea1520c9689e9383fab3f6 (master)
*** Bug 622362 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > (In reply to comment #10) > > In NM 0.8, disabling the wireless network is not persistent after a boot. > > I would expect that settings are kept between reboots. > > Yeah, though that's a different bug than this one. Really? It sounds very similar while still different. Anyway, also GNOME logoff/logon won't retain the disabled status.