Version: 0.9 (using KDE 4.6.0) OS: Linux KNM applet from current GIT. When user flips hardware hardware rfkill switch, NM temporary disables wireless; in response to this event KNM sends additional request to NM to disable wireless, which is now interpreted by NM as user request so wireless gets permanently disabled, even after WiFi is turned on again until explicitly enabled by user again. See http://mail.gnome.org/archives/networkmanager-list/2011-March/msg00063.html with detail explanation of Dan Williams. KNM should not re-emit signal in this case. From GUI point of view correct behaviour would be un-check and make "Enable Wireless" button inactive until NM signals that wireless is available again. Reproducible: Always Steps to Reproduce: Switch off WiFi using hardware switch (on a system supporting rfkill). Switch it on using hardware switch again. Actual Results: Wireless in NM remains disabled Expected Results: Wireless should be automatically re-enabled
// Add Gokcen to CC
I confirm that this also happens on my machine. network-manager: 0.8.1+git.20101009t040337.01fa170-0ubuntu1~nmt1~lucid1 from http://ppa.launchpad.net/network-manager/trunk/ubuntu/ plasma-widget-networkmanagement: 0.9~svn1137272-0ubuntu2~lucid1~ppa1 from http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu/ OS: Kubuntu 10.04 64bits.
The problem is a missing wirelessHardwareEnabledChanged signal emit in Solid' NetworkManager backend: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/2ec6533494a23164ee9c2de4ab65d5fa372aff5c Without that emit Plasma NM is not able to recognise wireless rfkill state changes. The fix will be available in KDE SC 4.6.2 but unfortunately until then you will have to apply the fix to Solid manually.
Git commit 591a85e2c62e10f2792517343f6fdd6316a933b6 by Lamarque V. Souza. Committed on 08/03/2011 at 22:31. Pushed by lvsouza into branch 'master'. Sanitize the Networking, Wireless and Wwan checkbox handling according to Dan Williams comments in http://mail.gnome.org/archives/networkmanager-list/2011-March/msg00063.html Quoting: Possibly. Here's what *might* be going on... usually GUI tools will hook a UI element like a checkbox up to a property so that the checkbox automatically updates when that property changes. In the case of the WiFi Enabled property, that's clearly the right thing to do as other tools besides the applet could toggle that property without the applet's knowledge, but the applet must still reflect the current state as provided by NetworkManager. But the applet must also respond to *user* initiated changes to that checkbox as well. Usually that happens when the applet attaches to the signal/slot that indicates the checkbox has been toggled, and upon receipt of that signal it tells NM to enable/disable wifi. But if the code also toggles the checkbox as a result of NM sending a property-changed signal, that could result in the NM change signal toggling the checkbox, which the applet interprets as the user clicking on the checkbox, which the applet then handles by telling NM to explicitly enable/disable wireless. Basically, the applet should never update NM's user wifi state based on signals from NM, or from NM's wifi hardware enabled state. Lamarque: although that is not the cause of the problem that started that mailing thread I think it is a good idea to avoid sending unneeded NM calls to change Networking, Wireless or Wwan state. I also added two KDE_IS_VERSION(4.6.2) #if's to really fix the problem for KDE SC < 4.6.2 users. CCBUG: 267967 M +50 -71 applet/nmpopup.cpp M +0 -4 applet/nmpopup.h http://commits.kde.org/networkmanagement/591a85e2c62e10f2792517343f6fdd6316a933b6