Permanently disable built-in bluetooth and use USB

Question

After 5 years my laptop is in perfect condition (still).

But my built-in bluetooth is not what it used to be (thanks to the extensive use of it) and fails to load at boot pretty much. Because of extensive use I opted to buy a 10 dollar bluetooth stick which took over the job of the built-in one.

However, the built-in one is mostly not on but sometimes it still gives a spark. At that times it's sometimes really annoying because it just screws my settings and overwrites several things.

My question: how can I make sure the built-in bluetooth is permanently disabled while the USB-device is still able to send my audio/pointing devices/... through.

System: Linux Mint 18 (Base: Ubuntu 16.04)

lsusb-output:

jeroen@laptop ~ $ lsusb
Bus 002 Device 002: ID 5986:02ac Acer, Inc 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 138a:0018 Validity Sensors, Inc. Fingerprint scanner
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
(Built-in BT) Bus 003 Device 004: ID 0a5c:21b4 Broadcom Corp. BCM2070 Bluetooth 2.1 + EDR
(USB-BT) Bus 003 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Update: test output

(as requested by Dirkt)

jeroen@laptop ~ $ sudo hcitool dev
Devices:
    hci0    00:1B:DC:0F:73:5D
    hci1    CC:52:AF:A8:71:B5
## Plugged out the USB-BT dongle
jeroen@laptop ~ $ sudo hcitool dev
Devices:
    hci1    CC:52:AF:A8:71:B5
## Plugged in the USB-BT dongle
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: no
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill block 5
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: no
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill block 6
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: yes
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill block 8
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: yes
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: yes
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill unblock 8
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: no
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill unblock 6
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: no
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no
jeroen@laptop ~ $ sudo rfkill unblock 5
jeroen@laptop ~ $ sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
4: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
5: hp-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no
6: hci1: Bluetooth
    Soft blocked: no
    Hard blocked: no
8: hci0: Bluetooth
    Soft blocked: no
    Hard blocked: no

Solution 1

Option 1: Use rfkill.

This will disable transmitting on the device that is blocked, and usually also put the drivers in a "down" state. rfkill help for commands, rfkill list to list devices which can be rfkill'ed, rfkill block <index>|<type> to block it. You might need an index, and I don't know if indices stay consistent across boots, so you'll probably need to write a little script with grep, cut etc to be on the safe side. You may need to install the package for the rfkill command.

Edit: If you are worried about changing indices, do something like

HCI=`hcitool dev | grep '00:11:22:33:44:55' | cut -f2`
INDEX=`rfkill list | grep $HCI | cut -d: -f1`

(but of course with the MAC-address of your internal bluetooth adapter), and $INDEX should contain the index of it. I can't test this, as I don't have hardware with more than one bluetooth adapter.

Another way would be to use udev rules to make special names for the known adapters, but that's probably more difficult to figure out than to use the above two lines.

In the end, there's no alternative to using the rfkill kernel features to completely disable a bluetooth radio, though there may be other commandline interfaces to it I'm not aware of.

Option 2: Blacklist kernel module

If after boot the built-in bluetooth device is in a disabled state, and the kernel driver is compiled as a module, you can keep the driver from loading and enabling the device by blacklisting it. Use lsmod to list the modules currently loaded, and have a look at dmesg or your syslog after boot to identify the driver for your built-in bluetooth device. Blacklisting it depends on the distribution you use, e.g. on Debian (and probably Ubuntu, too), make a file in /etc/modprobe.d/ that contains the line blacklist <modulname>. See man modprobe.d for details.

If the built-in bluetooth device boots in enabled state, blacklisting the driver will prevent you from using it, but if it's broken, it may still transmit stuff.

Solution 2

You can create a udev rule to disable the internal Bluetooth. Put the following in /etc/udev/rules.d/81-bluetooth-hci.rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0a5c", ATTRS{idProduct}=="21b4", ATTR{authorized}="0"

And reboot.

Solution found on AskUbuntu.

Comments

[Jeroen De Meerleer]

Isn't this also going to disable the USB-bluetooth as they are both use btusb driver (The built-in uses an internal USB-port)

[Jeroen De Meerleer]

The first option is not an option as the ports are not consistent :(

[dirkt]

I've never actually used a system with two BT adapters, but I'd assume they show up differently under rfkill list. What's the output of that command on your system?

[Jeroen De Meerleer]

I just checked the rfkill and blacklist options and unfortunelatey both options did not work. The blacklist didn't work for some reason (the special btbcm driver mentioned in lsmod did load after reboot) and the rfkill option disabled both bluetooth-drivers.

[dirkt]

Could you post the output of rfkill list? You used an index for rfkill block, didn't you? If it disabled BT devices both using an index, that looks like a bug. If the bug is in rfkill, maybe one can use some /sys or /proc interface directly, I'd have to look into that. If you can't successfully blacklist a driver, there's probably some mistake in the configuration file you wrote.

[Jeroen De Meerleer]

I updated the original post with rfkill output. Also, I did indeed use rfkill block using the script you provided in above answer.

[dirkt]

To test: First, do it manually, ignore the script. Figure out which device is which (e.g. hcitool dev, if you are unsure how to interpret the output, post that, too). You have 3 BT devices instead of the expected 2, so something else is going on. Maybe have a look demsg/syslog. To actually test, pick each of the 3 BT devices in turn, do rfkill block <index>, do rfkill list again to verify that only this device is blocked, then unblock it and try the next. It may be that one of the adapters provides two devices, so they might be hardblocked as a pair.

[dirkt]

If no matter what index you chose, always all 3 BT devices get blocked, there's a bug somewhere, and we'll have to have a closer look.

[Jeroen De Meerleer]

thanks for all efforts. I really appreciate it. Right now the builtin-bluetooth is down and I checked the journalctl and found this okt 10 18:27:44 laptop kernel: Bluetooth: hci0 hardware error 0x37 hci0 is quite consistent and I have the feeling 0x37 could be consistent too. Would there be an option in permanently disabling hci0?

[dirkt]

It would help if you'd be a bit more forthcoming with information, because I'm basically flying in the dark and can't see anything. The question is still which of those 3 devices is which. If you don't know how to figure that out from the MAC address, please post the output of hcitool dev. I also don't know which "both" bluetooth drivers are blocked, as you said. Assuming hci0/hci1 are the pair of interfaces provided by the broken in-built BT, then yes, it'd make sense to block them, and keep hp-bluetooth. But first we must know which is which.

[dirkt]

So if I say "test this and this", please give some feedback in the form "I did X, and Y happened, and here's the output". Otherwise I'm just guessing wildly. Troubleshooting is a process, not something where you know all the answers in advance.

[Jeroen De Meerleer]

when blocking hci0 the whole bluetooth service goes down and by manually starting it both devices are up. When blocking hci1, the complete bluetooth service stays up. Blocking the hp-bluetooth doesn't do anything.

[Jeroen De Meerleer]

I have ran hcitool dev twice. 1 time with the USB-dongle insert and another time without. Turns out hci0 dissappears when taking out the dongle.

[dirkt]

You may have to configure the "bluetooth service" to not use hci0, and not unblock it when it goes up. Try turning the "bluetooth service" off first, then block hci0, do a rfkill list and verify only hci0 is blocked, and nothing else. If that's the case, everything is working correctly, and there's no bug.

[dirkt]

You probably have systemd for Mint/Ubunutu, which I don't use, so I can't walk you through the BT configuration. And I still don't understand where "hp-bluetooth" comes from. Is there anything in dmesg/syslog about it? If something "gives a spark", it might be also this one.

[dirkt]

Googling finds that the hp_wmi module seems to be responsible for hp-bluetooth and hp-wifi, and it also can interfere with blocking. Do you have an HP Laptop? What happens if you unload/blacklist hp_wmi?

[Jeroen De Meerleer]

Let us continue this discussion in chat.