[SOLVED] Prevent hardware switch from enabling bluetooth

boughtonp · 02-26-2021, 10:59 AM

I have a hardware radio switch. Unlike the various search results I'm finding, the switch works and is not itself a problem: If I turn if off, it disables wifi, and if I turn it on, it enables wifi.

What is happening that I do not want is having bluetooth re-enabled in software whenever the switch is turned on again, because it wasn't enabled before, (and I want it off at all times unless I explicitly request it).

In summary, given a current state of:

Code:

$ sudo rfkill --output-all
ID TYPE      DEVICE              TYPE-DESC         SOFT      HARD
 0 bluetooth tpacpi_bluetooth_sw Bluetooth      blocked unblocked
 2 wlan      phy0                Wireless LAN unblocked unblocked

[switch off]

Code:

$ sudo rfkill --output-all
ID TYPE      DEVICE              TYPE-DESC       SOFT    HARD
 0 bluetooth tpacpi_bluetooth_sw Bluetooth    blocked blocked
 2 wlan      phy0                Wireless LAN blocked blocked

[switch on]

Code:

$ sudo rfkill --output-all
ID TYPE      DEVICE              TYPE-DESC         SOFT      HARD
 0 bluetooth tpacpi_bluetooth_sw Bluetooth    unblocked unblocked
 2 wlan      phy0                Wireless LAN unblocked unblocked
 5 bluetooth hci0                Bluetooth      blocked unblocked

It seems the correct behaviour should be to record the software state when the switch is turned off, then restore that state when the switch is toggled on, but I'm guessing that's a kernel level issue so even if I raised a bug and got agreement it would take time to filter through.

I don't want to have to manually run "sudo rfkill block bluetooth" to disable bluetooth - I either want that command performed automatically, or to disable bluetooth in such a way that it requires a manual action from me to turn back on.

Distro is Debian Buster.

In "/var/log/kern.log" there are the following entries caused by turning it off and on again:

Code:

Feb 26 16:33:47 mycomputer kernel: [  997.411262] iwlwifi 0000:02:00.0: RF_KILL bit toggled to disable radio.
Feb 26 16:33:47 mycomputer kernel: [  997.411265] iwlwifi 0000:02:00.0: reporting RF_KILL (radio disabled)
Feb 26 16:33:47 mycomputer kernel: [  997.440882] iwlwifi 0000:02:00.0: RF_KILL bit toggled to disable radio.
Feb 26 16:33:50 mycomputer kernel: [ 1000.288581] iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio.
Feb 26 16:33:50 mycomputer kernel: [ 1000.288586] iwlwifi 0000:02:00.0: reporting RF_KILL (radio enabled)

I would like to set an event listener which reacts to the RF_KILL bit being toggled, but I'm having no luck finding any explanations as to if and how this can be done.

(I'm not interested in running a scheduled task; I want to react to the event immediately, or require manual intervention to turn on bluetooth.)

On the disabling front, I found a reference to AutoEnable in "/etc/bluetooth/main.conf" but changing that from true to false then restarting did not solve the problem.

Any ideas?

jefro · 02-26-2021, 02:35 PM

Maybe at boot make a script to force what you want??

Normally I'd say to remove driver for bluetooth but that may be a problem as it may be that the device you have runs both wifi and bluetooth.

Emerson · 02-26-2021, 02:40 PM

When you flip the switch, is there any event registered in the logs which could be used as a trigger?

boughtonp · 02-27-2021, 06:29 AM

Quote:

Originally Posted by jefro

Maybe at boot make a script to force what you want??

What I want is to modify or react to the hardware radio switch being turned on.

Imagine a physical network cable being removed or connected whilst the machine is running - that's similar to what the switch does - but when re-connecting it turns on bluetooth too, and I want to counter that.

Quote:

Originally Posted by Emerson

When you flip the switch, is there any event registered in the logs which could be used as a trigger?

Isn't that what the kern.log excerpt I posted is? I don't know how to respond to such a trigger directly - I don't want to poll the log file, and there appears to be a confusing selection of libraries that may or not be relevant.

On further searching I found a page which states:

Quote:

Originally Posted by https://www.kernel.org/doc/html/latest/driver-api/rfkill.html

After an application opens /dev/rfkill, it can read the current state of all devices. Changes can be obtained by either polling the descriptor for hotplug or state change events or by listening for uevents emitted by the rfkill core framework.

Ok, so uevents sounds like what I want, and it seems for that I need udev/udevadm; and a quick test with "udevadm monitor" shows various events triggered when the switch is changed, so I guess I need to go investigate how I can hook into that.

boughtonp · 02-27-2021, 07:15 AM

Ok, so triggerring a script in response to a uevent means creating a udev rule file in /etc/udev/rules.d/

I used "udevadm monitor --property" to confirm the correct values to go in the rule:

Code:

ACTION=="change", SUBSYSTEM=="rfkill", ENV{RFKILL_TYPE}=="bluetooth", ENV{RFKILL_STATE}=="0", RUN=="/usr/sbin/rfkill block bluetooth"

Save the file and run "sudo udevadm control --reload" for it to take effect.

The absolute path in the RUN matters - when I first tried "rfkill block bluetooth" (and other variants) I was getting a daemon.log entry saying "Process 'rfkill block bluetooth' failed with exit code 1."

Now I can toggle the switch and wifi toggles correctly whilst bluetooth gets turned off immediately.

Success!

jefro · 02-27-2021, 02:23 PM

Great, thanks for the update and solution.

boughtonp · 06-27-2021, 06:51 AM

For future reference, it took too long to figure out that when temporarily re-enabling bluetooth, "rfkill unblock bluetooth" needs to be followed by "systemctl start bluetooth" - if you forget that second stage the error messages weren't very helpful.