Hmmm, yeah, it's probably a sony-wifi platform driver problem.

Try removing the driver and if everything works, then report to kernel:

# rmmod sony-wifi

or to make it permanently blocked you can use:
# echo "blacklist sony-wifi" >> /etc/modprobe.d/blacklist-sonywifi.conf

Sorry, I'd rather not blacklist it except for debugging purposes. It is absolutely required to get the built-in WWAN card working, and I sometimes use it. Also it is required for brightness keys.

this is btw not the sony-wifi driver, but a part of the sony-laptop driver

I have tried blacklisting sony-laptop driver. Result: wi-fi works as expected unless it has been disabled by another OS (that could be Windows) through this platform interface during the previous boot.

Forgot to tell: if the wi-fi has been disabled in the other OS through the platform interface, then there is no way to turn it on without loading the sony-laptop driver. It just remains hw-blocked.

*** Bug 681020 has been marked as a duplicate of this bug. ***

I've discussed this by email with Mattia Dongili <malattia@linux.it> who maintains the sony-laptop module.

What happens here is that sony-laptop exports indeed itself an rfkill (sony-wifi). This rfkill has its "soft block" directly linked to the "hard block" of the one from phy0 (iwlwifi in this case).

So what Network-Manager does here, is that it soft-blocks all rfkill of type "wifi", and doing this triggers an hard block, since soft blocking sony-wifi triggers hard block on phy0.

According to Mattia, it's a normal and good thing that the soft block from sony-wifi is tighted to the hard one of phy0. And I trust him since he knows the hardware well, and confirmed this under Windows too.

The problem here is that NM should probably either don't touch an rfkill that is not tight to the interface it's trying to shut down.

Julien, your last phrase in the comment above seems to be incomplete. It contains the word "either", but not "or". And it doesn't specify the behaviour that NM should attempt when it sees a laptop that was rfkilled from Windows (i.e. with sony-wifi soft-blocked).

I wrote either thinking I would see a second option, but finally I didn't, so just read the sentence like there was no "either". Sorry. :)

But as you point out, there is probably a second choice here, at least to handle the case you described.

I think a second approach would be to say "hardware disabled" if and ONLY if ALL wifi rfkill are *hard* blocked.

So in the case like wifi rfkilled from Windows, or rfkilled by current NM you end up with:

phy0: soft-block hard-block
sony-wifi: soft-block

NM should allow you to activate the Wifi because not every wifi rfkill are hard blocked. Then it would unblock all rfkill, starting by the ones that are not hard-blocked. It would starts with unblocking sony-wifi, so at step one we end up with:

phy0: soft-block
sony-wifi: not blocked

NM should detect that phy0 changed, and that is now unblockable, so it would continue and unblock phy0:

phy0: not blocked
sony-wifi: not blocked

And that would work. :)

hmm, I tested this on my HP and it works correctly.  NetworkManager allows the "platform" killswitch state to override the "phy" state when the platform switch is either hard or soft blocked.

NM WHE = NM Wireless Hardware Enabled, which controls whether the menu items are sensitive or not.  You can find it by running "nmcli nm" and looking at the WIFI-HARDWARE field.

Thus on my HP 2530p (using hp-wmi) when turning off wifi via NetworkManager I get:

hp-wmi: softblock
phy0:   softblock & hardblock
NM WHE: enabled

meaning you can toggle the rfkill again via NM.  This is using NetworkManager 0.9.6, but the commit (bug #655773) that overrides PHY state with platform state is quite old and was resolved last year.  I suspect you have that commit.

What then happens on my laptop when I *unblock* hp-wmi manually with 'rfkill' like you did in comment #1, is the following:

hp-wmi: unblocked
phy0:   softblock
NM WHE: enabled

So in all these cases, NM's WHE has remained enabled, meaning I can still toggle WiFi from the menu.

My rfkill behavior matches with yours, so the issue appears to be that the "NM WHE" bits aren't being set correctly.  Can you verify using 'nmcli nm' that the WHE state either matches or does not match the state that I get (ie, always enabled)?

If it matches the state that I get, then the problem is in the GNOME3 network applet, and this bug should be moved to the "gnome-shell" project under the "network" component.

If it doesn't match the states I get, then the problem is in NetworkManager, and we should debug further.  To do this, you'll want to stop the NetworkManager service using your distro's normal mechanisms, and then run it manually like so:

NetworkManager --no-daemon --log-level=debug --log-domains=core,device,hw,rfkill

and then attach the logs here so we can determine what's going on with the rfkill handling.

Switching Wireless off via the GNOME3 network applet:

NetworkManager[30152]: <debug> [1345218722.470197] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill0'
NetworkManager[30152]: <debug> [1345218722.470670] [nm-udev-manager.c:232] recheck_killswitches(): WiFi rfkill state now 'soft-blocked'
NetworkManager[30152]: <debug> [1345218722.470702] [nm-manager.c:1479] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 0
NetworkManager[30152]: <info> WiFi now disabled by radio killswitch
NetworkManager[30152]: <debug> [1345218722.481245] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill12'
NetworkManager[30152]: <debug> [1345218722.484661] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill12'

hp-wmi: softblock
phy0:   hardblock & softblock
NM WHE: enabled


Switching wireless back on via the GNOME3 network applet:

NetworkManager[30152]: <debug> [1345218803.645287] [nm-manager.c:4119] manager_radio_user_toggled(): (WiFi): setting radio enabled by user
NetworkManager[30152]: <debug> [1345218803.992411] [nm-manager.c:1331] manager_update_radio_enabled(): (wlan13): setting radio enabled
NetworkManager[30152]: <info> (wlan13): bringing up device.
NetworkManager[30152]: <info> WiFi hardware radio set enabled
NetworkManager[30152]: <debug> [1345218804.43454] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill12'
NetworkManager[30152]: <debug> [1345218804.43822] [nm-udev-manager.c:232] recheck_killswitches(): WiFi rfkill state now 'unblocked'
NetworkManager[30152]: <debug> [1345218804.43854] [nm-manager.c:1479] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 1
NetworkManager[30152]: <info> WiFi now enabled by radio killswitch
NetworkManager[30152]: <debug> [1345218804.43905] [nm-manager.c:1331] manager_update_radio_enabled(): (wlan13): setting radio enabled
NetworkManager[30152]: <info> (wlan13): bringing up device.
NetworkManager[30152]: <debug> [1345218804.166407] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill12'
NetworkManager[30152]: <debug> [1345218804.167359] [nm-udev-manager.c:543] handle_uevent(): UDEV event: action 'change' subsys 'rfkill' device 'rfkill0'

hp-wmi: unblocked
phy0:   unblocked
NM WHE: enabled

(In reply to comment #10)
> Thus on my HP 2530p (using hp-wmi) when turning off wifi via NetworkManager I
> get:
> 
> hp-wmi: softblock
> phy0:   softblock & hardblock
> NM WHE: enabled

And I get this:

# LC_ALL=C nmcli nm
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         disconnected    disabled        disabled   enabled         enabled   

> 
> meaning you can toggle the rfkill again via NM.  This is using NetworkManager
> 0.9.6, but the commit (bug #655773) that overrides PHY state with platform
> state is quite old and was resolved last year.  I suspect you have that commit.

I am running 0.9.4 with r5 of Gentoo patches.

> What then happens on my laptop when I *unblock* hp-wmi manually with 'rfkill'
> like you did in comment #1, is the following:
> 
> hp-wmi: unblocked
> phy0:   softblock
> NM WHE: enabled

# LC_ALL=C nmcli nm
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         disconnected    enabled         disabled   enabled         enabled   


> So in all these cases, NM's WHE has remained enabled, meaning I can still
> toggle WiFi from the menu.

As explained above, this is not the case here.

> If it doesn't match the states I get, then the problem is in NetworkManager,
> and we should debug further.  To do this, you'll want to stop the
> NetworkManager service using your distro's normal mechanisms, and then run it
> manually like so:
> 
> NetworkManager --no-daemon --log-level=debug
> --log-domains=core,device,hw,rfkill
> 
> and then attach the logs here so we can determine what's going on with the
> rfkill handling.

Will do this now. Note that the logs are from 0.9.4, so it might be a bug already fixed in 0.9.6, I don't know.

Created attachment 221636 [details]
The log as asked in comment #10

Created attachment 221642 [details]
Similar log from 0.9.6.0

The bug still exists in version 0.9.6.0 of NetworkManager. The log illustrates connection to the "t503" network, disabling wireless via nm-applet (at this point it is impossible to reenable via GUI), unblocking sony-wifi using "rfkill unblock 0", and then connecting to the "t503" network again.

BTW "nmcli nm wifi off" is enough to trigger the bug - "nmcli nm wifi on" does not lift the hardblock (it connects successfully after "rfkill unblock 0"). So the bug is definitely not related to nm-applet.

One more thing you can do for me.  Perhaps the sony-wifi switch isn't getting detected as a platform switch.

sudo udevadm info --query=property --attribute-walk --path=/sys/class/rfkill/rfkill0

the actual device won't say, but the parents should be "platform" devices:

  looking at parent device '/devices/platform/hp-wmi':
    KERNELS=="hp-wmi"
    SUBSYSTEMS=="platform"
    DRIVERS=="hp-wmi"
    ATTRS{als}=="0"
    ATTRS{dock}=="0"
    ATTRS{display}=="65792"
    ATTRS{tablet}=="0"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

if that looks like mine does, then are you willing to test out enhanced logging patches on top of 0.9.6 that help isolate the problem?

Ok, seems like some drivers (sony-laptop, classmate, toshiba, and ideapad) all root the rfkill switch under "acpi" not "platform".  So if you can run that udevadm command, we can add an additional check for 'acpi' switches and things will work for you.

Commit ef4f6a2e55784fec4498d364b6181c3ca36ab7b0 adds support for detecting "acpi" subsystem devices as platform switches.  If you're able to test latest git master, that would be great, otherwise just cherry-pick the commit if you can to your current package version.

I'll close the bug as fixed for now, please re-open if the fix doesn't work.  Thanks!

Fixed indeed (tested by applying the patch to already-downloaded NetworkManager source). Unfortunately, as my ISP failed today, now I have to use rather expensive GPRS, and would rather not download the full git tree over this connection.

Applying only the patch to your existing sources should be fine.  Thanks for testing!