Bug 599002

Note that for wwan, rfkill just means whether the device is powered, not whether it is enabled.  When WWAN is rfkilled, it drops off the USB bus completely because its power is cut.  When WWAN is not rfkilled, the card is available but is not necessarily powered up fully.  It's an odd situation because WWAN is usually USB-connected, while wifi is PCI connected, and with PCI stuff doesn't usually drop off the bus when disabled (except with the Acer eepc).
l

Wifi devices are now softkilled and soft-unkilled as of 67e092abcbdece45f4753383797000d4ed49f3dc upstream.  This is a 0.9 only change and thus F15+.

(In reply to comment #1)
> Note that for wwan, rfkill just means whether the device is powered, not
> whether it is enabled.
>  When WWAN is rfkilled, it drops off the USB bus
> completely because its power is cut.  When WWAN is not rfkilled, the card is
> available but is not necessarily powered up fully.

I understand what you're saying here, but this is not true for WWAN integrated
into laptops, at least not the WWAN in my Dell latitude E6400...

Directly after boot, hw rfkill switch at radio(s) on position:
[hans@localhost ~]$ rfkill list
0: dell-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: dell-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: dell-wwan: Wireless WAN
        Soft blocked: no
        Hard blocked: no
3: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
4: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
[hans@localhost ~]$ lsusb | grep Huawei
Bus 002 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem

Status leds for bluetooth, wwan and wlan all 3 on

***

hw rfkill switch moved to radio(s) off position:
[hans@localhost ~]$ rfkill list
0: dell-wifi: Wireless LAN
        Soft blocked: yes
        Hard blocked: yes
1: dell-bluetooth: Bluetooth
        Soft blocked: yes
        Hard blocked: yes
2: dell-wwan: Wireless WAN
        Soft blocked: yes
        Hard blocked: yes
3: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: yes
[hans@localhost ~]$ lsusb | grep Huawei
Bus 002 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem

Status leds for bluetooth, wwan and wlan all 3 off

Notice that the "hci0: Bluetooth" rfkill entry is gone, because the (internal) bluetooth device actually
gets unplugged from the usb bus, as you described for wwan, but the wwan card does not get unplugged.

***

hw rfkill switch back at radio(s) on position, do a soft rfkill of the wwan:
[hans@localhost ~]$ rfkill block wwan
result:
[hans@localhost ~]$ rfkill list
0: dell-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: dell-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: dell-wwan: Wireless WAN
        Soft blocked: yes
        Hard blocked: no
3: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
5: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
[hans@localhost ~]$ lsusb | grep Huawei
Bus 002 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem

Status leds for bluetooth, wlan on, for wwan off

This is the status which I would like to get in through NetworkManager / the gnome-shell
NetworkManager "applet".

(In reply to comment #2)
> Wifi devices are now softkilled and soft-unkilled as of
> 67e092abcbdece45f4753383797000d4ed49f3dc upstream.  This is a 0.9 only change
> and thus F15+.

Right, I already noticed that, works fine for me, thanks!

Some more data. I noticed in NetworkManager update in yesterdays new packages with the
following changelog:

NetworkManager-0.8.998-3.git20110419.fc15
-----------------------------------------
* Tue Apr 19 2011 Dan Williams <dcbw> - 0.8.998-3.git20110419
- core: systemd and startup enhancements for NFS mounts
- core: more efficient startup process
- core: fix handling of multiple logins when one is inactive
- core: fix handling of S390/Hercules CTC network interfaces (rh #641986)
- core: support Easytether interfaces for Android phones
- core: fix handling of WWAN enable/disable states
- ifcfg-rh: harmonize handling if IPADDR/PREFIX/NETMASK with initscripts (rh
#658907)
- applet: fix connection to WPA Enterprise networks (rh #694765)

The "core: fix handling of WWAN enable/disable states" triggered me to do some
testing with the integrated wwan card in my laptop. With this new NM version the
gnome-shell UI has some inconsistencies / issues. I filed a separate bug
against gnome-shell for this, see bug 699349.

NetworkManager-0.8.998-4.git20110427.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.998-4.git20110427.fc15

(In reply to comment #5)
> NetworkManager-0.8.998-4.git20110427.fc15 has been submitted as an update for
> Fedora 15.
> https://admin.fedoraproject.org/updates/NetworkManager-0.8.998-4.git20110427.fc15

Hi,

As discussed this update indeed makes NM control the rfkill switch for wireless, which is very nice, thanks! But NM does not (yet) control the rfkill switch for wwan devices, how do you want to track that, should I file a new bug for that ?

Thanks & Regards,

Hans

Package NetworkManager-0.8.998-4.git20110427.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.998-4.git20110427.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.998-4.git20110427.fc15
then log in and leave karma (feedback).

NetworkManager-0.8.998-4.git20110427.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

I'm going to open a new bug for the wwan rfkill thingie so that that does not fall through the cracks.