# RFKILL now makes Trouble with Baselayout-2

## charles17

After kernel upgrade from 2.5.29-r5 to 2.6.32-r7 RFKILL seems to be broken. 

With gentoo-sources-2.6.29-r5 on my laptop (Compaq nc6320) the HW RFKILL button properly switched radio off an on. 

After kernel upgrade to gentoo-sources-2.6.32-r7 I can use it to switch radio off.  But then the button is dead and doesn't do anything.  To bring network up again I have to use "/etc/init.d/net.wlan0 restart" instead.

I know there has been changes in the kernel configuration and in my 2.6.32-r7 kernel I have 

```
grep -e 'RFKILL\|IWL .conf

CONFIG_RFKILL=y

CONFIG_RFKILL_LEDS=y

CONFIG_RFKILL_INPUT=y

CONFIG_IWLWIFI=m

CONFIG_IWLWIFI_LEDS=y

# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set

# CONFIG_IWLWIFI_DEBUG is not set

# CONFIG_IWLAGN is not set

CONFIG_IWL3945=m

CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y

```

Is there a kernel bug with RFKILL or do I need to modify something else except the kernel itself?

Any help highly appreciatedLast edited by charles17 on Sat May 07, 2011 3:58 pm; edited 2 times in total

----------

## DONAHUE

```
emerge rfkill
```

 ?

----------

## charles17

Thanks for the hint. I've tried it, but emerging net-wireless/rfkill did not help.  The hardware RFKILL button is still dead after switch off.  

Anyway, net-wireless/rfkill is masked unstable.

Turning back to the old 2.6.29-r5 kernel solves the problem.  But how could I upgrade without having this rfkill problem?

----------

## DONAHUE

see if this helps

based on this I would suspect 2.5.29-r5 throws an acpi event and 2.6.32-r7 does not

----------

## charles17

Not sure if this is an acpi event.  I have something in the messages when switching off

```
Sep 13 18:00:09 server acpid: client 5122[0:0] has disconnected

Sep 13 18:00:31 server kernel: iwl3945 0000:08:00.0: Card state received: HW:Kill SW:On

Sep 13 18:00:31 server kernel: wlan0: deauthenticating from 00:1c:4a:46:4d:b0 by local choice (reason=3)

Sep 13 18:00:31 server kernel: iwl3945 0000:08:00.0: Error sending REPLY_LEDS_CMD: enqueue_hcmd failed: -5

Sep 13 18:00:31 server dhcpcd[5979]: wlan0: carrier lost

Sep 13 18:00:31 server wpa_cli: interface wlan0 DISCONNECTED

Sep 13 18:00:32 server fetchmail[6188]: terminated with signal 15

Sep 13 18:00:32 server ntpd[6325]: Terminating

Sep 13 18:00:32 server dhcpcd[5979]: wlan0: received SIGTERM, stopping

```

with HW:KILL in the second line kernel: iwl3945 0000:08:00.0: Card state received: HW:Kill SW:On.

But there is no such event when I press the button again. I have to manually restart "/etc/init.d/wlan0 restart".

The workaround by AM088 seems not to be applicable for me since I don't have /etc/init.d /wpa_supplicant.  Instead wpa_supplicant will be started when wlan0 comes up.

Any solution without having to create additional scripts and udev rules?

----------

## DONAHUE

So the fixed script which may work with both soft and hard blocks and should be for your situation is:

Suggest 

```
nano /etc/udev/rfkill.sh
```

 fill it with:  *Quote:*   

> #!/bin/bash 
> 
> if [ "${RFKILL_STATE}" == 1 ]; then 
> 
>         /etc/init.d/net.wlan0 start 
> ...

  make it executable 

```
chmod 775 /etc/udev/rfkill.sh
```

reboot and test the button.

if fails: error messages?

use button to kill wlan0

```
rfkill unblock wifi
```

push button. wlan0 start? if not:

```
rfkill unblock wifi
```

wlan0 start?

----------

## charles17

Now it works, even without reboot

```
KERNEL[1284574130.440528] change   /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/ieee80211/phy0/rfkill0 (rfkill)

KERNEL[1284574131.373197] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::radio (leds)

KERNEL[1284574131.373322] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::assoc (leds)

UDEV  [1284574131.373503] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::radio (leds)

KERNEL[1284574131.373717] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::RX (leds)

KERNEL[1284574131.373857] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::TX (leds)

UDEV  [1284574131.373876] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::RX (leds)

UDEV  [1284574131.374410] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::assoc (leds)

UDEV  [1284574131.374711] add      /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/leds/iwl-phy0::TX (leds)

UDEV  [1284574131.853079] change   /devices/pci0000:00/0000:00:1c.0/0000:08:00.0/ieee80211/phy0/rfkill0 (rfkill)

```

Thanks a lot for your help.

----------

## DONAHUE

Well done. Pls edit title of your first post to include [Solved] for the next guy.

Thanks go to AM088.

----------

## aCOSwt

 *charles17 wrote:*   

> After kernel upgrade from 2.5.29-r5 to 2.6.32-r7

 

I apologize for going off topic however I am interested in the facts governing a decision to upgrade from 2.5.29 to 2.6.32 and not to a newer version.

----------

## charles17

The kernel's CONFIG_RFKILL seems to be broken in 2.6.32-r7.  But you can use that kernel with the workaround provided in this thread.

Disabling CONFIG_RFKILL would enable the buttons capabilities but only very unreliably.  So you'd better have CONFIG_RFKILL=y and use the mentioned udev rule.  It works.

----------

## charles17

Now, 8 months later and after migration to openrc and baselayout-2, I am getting troubles again.

Each time on booting the system hangs with a one minute delay waiting for uevents being processed.  The message is

```
udevadm settle - timeout of 60 seconds reached, the event queue contains

/sys/devices/pci0000:00/0000:00:1c.0/0000:08:00.0/ieee80211/phy0/rfkill0

/sys/devices/pci0000:00/0000:00:1c.0/0000:08:00.0/ieee80211/phy0/rfkill0

/sys/devices/pci0000:00/0000:00:1c.0/0000:08:00.0/ieee80211/phy0/rfkill0
```

Somehow, baselayout-2 does no longer like my existing rule and script

 */etc/udev/rules.d/40-rfkill.rules wrote:*   

> SUBSYSTEM=="rfkill", ATTR{type}=="wlan", RUN+="/etc/udev/rfkill.sh"
> 
> 

  */etc/udev/rfkill.sh wrote:*   

> #!/bin/bash
> 
> if [ "${RFKILL_STATE}" == 1 ]; then
> 
>         /etc/init.d/net.wlan0 start
> ...

 

Disabling above rule would clearly solve the timeout delay on boot, so I am almost sure something in the script is incompatible with the new Baselayout-2.

No clue how to adjust for the new boot process.  Could you help again, please?

----------

