Hide Forgot
rfkill has 2 "controls" per device a hard and a soft on/off. The hard control is controlled by a hardware switch, where as the soft control can be set by software. On my Dell Latitude E6400 in which I recently put internal bluetooth and wwan mini pci express cards. There is a single "wifi" switch which turns the transmitter for all 3 (wlan, wwan and bluetooth) off. To save battery I would like to turn of just 1 or 2. I can do this from the cmdline with the rfkill command, controlling the soft control of the 3 separate rfkill devices the dell-laptop module creates. Doing so turns of the resp. leds on the laptop and one would hope also the actual transmitter. Currently nm-applet has checkboxes in its right click menu for enabling / disabling wlan and wwan. It would be nice if these would also control the soft rfkill toggle of the matching devices, so that turning off wireless will also turn of the transmitter of the wlan card, and turning off wwan likewise. 2 Related notes about the wwan support, and the "enable mobile broadband" checkbox: 1) Currently the "enable mobile broadband" does not seem to do anything at all independent of its state the mobile broadband menu always gets shown in the nm-applet left click menu. And I can always connect (assuming rfkill is set properly) 2) The wwan support seems to not integrate with rfkill at all, when rfkill is active for wlan this clearly gets shown in the left click menu, but for wwan nothing changes in the left click menu when the wwan associated rfkill is active. p.s. I know developers usually only get to see bugs and more bugs, so let me add this: Configuring my new wwan card was an absolute breeze. Plug in card, plug in sim, choose country + operator, blam everyhing works. That is amazing!! Many thanks for all your hard work on this very good tool!
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@redhat.com> - 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.