Getting cheap BT dongle to work--Ubuntu64

Chuck(G) · Mar 16, 2019

I picked up a few of the cheap USB Bluetooth dongles, but can't get them to work under either Ubutntu x64 nor Win7. They're registered by the driver software, but refuse to activate.

Here's the info for the dongle via lsusb:

Code:

Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

And what hciconfig says:

Code:

hci0:	Type: Primary  Bus: USB
	BD Address: 33:03:30:0A:C4:A3  ACL MTU: 360:4  SCO MTU: 0:0
	DOWN 
	RX bytes:553 acl:0 sco:0 events:28 errors:0
	TX bytes:368 acl:0 sco:0 commands:30 errors:0
	Features: 0xff 0xff 0xcd 0xfa 0xdb 0xbf 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: SLAVE ACCEPT

I can't get the dongle to UP status, no matter what I try.

If I try "sudo hciconfig hci0 up" I get the following message:

Code:

Can't init device hci0: Operation not supported (95)

Any ideas?
Oh yeah - lsb_release says:

Code:

Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.2 LTS
Release:	18.04
Codename:	bionic

TIA

ldkraemer · Mar 16, 2019

Chuck,
In a terminal type

Code:

dmesg | tail

to see if you have any error messages for the Firmware not being installed. Some of the older BT Dongles
need specific firmware loaded to support the BT Dongle.

I have blueman, bluez, and bluetooth installed on Debian (32 Bit) 8.x

You may have to install one of the firmware packages such as firmware-misc-nonfree.

I finally found that on a HP computer installed Linux on.

Larry

Chuck(G) · Mar 16, 2019

Hmmm, actually, to get past the cruft, it's better to dmesg | grep "Bluetooth"

I do see this message:

Code:

[   22.044068] Bluetooth: hci0: command 0x2007 tx timeout
[   24.925440] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   24.925442] Bluetooth: BNEP filters: protocol multicast
[   24.925539] Bluetooth: BNEP socket layer initialized

As far as "service bluetooth status" goes, I get:

Code:

● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset
   Active: active (running) since Fri 2019-03-15 22:11:14 PDT; 12min ago
     Docs: man:bluetoothd(8)
 Main PID: 703 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bluetooth.service
           └─703 /usr/lib/bluetooth/bluetoothd

Mar 15 22:11:14 Columbia bluetoothd[703]: Bluetooth daemon 5.50
Mar 15 22:11:14 Columbia bluetoothd[703]: Starting SDP server
Mar 15 22:11:14 Columbia bluetoothd[703]: Bluetooth management interface 1.14 in
Mar 15 22:11:14 Columbia systemd[1]: Starting Bluetooth service...
Mar 15 22:11:14 Columbia systemd[1]: Started Bluetooth service.

From this, I gather that the Bluetooth daemon is running just fine, but that the device itself isn't responding as expected to a command.

Chuck(G) · Mar 16, 2019

I have this one

I note that my lsusb says that my type is "Primary" and not "BR/EDR". I wonder if there's something there.

ldkraemer · Mar 16, 2019

Chuck,
Try these commands:
https://forums.linuxmint.com/viewtopic.php?f=49&t=73844&p=441402#p441402

sudo /etc/init.d/bluetooth restart

https://askubuntu.com/questions/779...e-silicon-radio-ltd-bluetooth-dongle-hci-mode

bluetoothctl
list

CNTL Z

mycomputer example:
larry@debian:~$ sudo /etc/init.d/bluetooth restart
larry@debian:~$ bluetoothctl
[NEW] Controller 00:1B:DC:06:AF:21 debian [default]
[NEW] Device 30:4B:07:EF:46:4D XT1710-02
[NEW] Device 5C:70:A3:D4:87:3D VS985 4G LTE
[NEW] Device 60:1D:91:9B:30:74 Moto E (4) Plus
[bluetooth]# list
Controller 00:1B:DC:06:AF:21 debian [default]
[bluetooth]#
[2]+ Stopped bluetoothctl
larry@debian:~$

Your Dongle should be detected.

Larry

Chuck(G) · Mar 16, 2019

Larry, I've done that before. This is what I get:

Code:

chuck@Columbia:~/Desktop$ sudo service bluetooth restart
[sudo] password for chuck: 
chuck@Columbia:~/Desktop$ sudo bluetoothctl
Agent registered
[bluetooth]# list
[bluetooth]# quit
chuck@Columbia:~/Desktop$

I suspect that there's a regression in the BT code. If I have time this weekend, I'll try the same on a copy of Ubuntu 14.04 LTS.

Chuck(G) · Mar 16, 2019

Tried the dongle on14.04LTS x32. Identical behavior.

Something tells me I'm missing a driver, but I don't know what it is.

sigh.

Chuck(G) · Mar 17, 2019

On a whim, I plugged the dongle on my Orange Pi PC and got this for hciconfig -a:

Code:

hci0:	Type: BR/EDR  Bus: USB
	BD Address: 33:03:30:0A:CC:7D  ACL MTU: 360:4  SCO MTU: 0:0
	UP RUNNING PSCAN ISCAN 
	RX bytes:587 acl:0 sco:0 events:38 errors:0
	TX bytes:3777 acl:0 sco:0 commands:38 errors:0
	Features: 0xff 0xff 0xcd 0xfa 0xdb 0xbf 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: SLAVE ACCEPT 
	Name: 'orangepipc'
	Class: 0x1c0000
	Service Classes: Rendering, Capturing, Object Transfer
	Device Class: Miscellaneous, 
	HCI Version: 4.0 (0x6)  Revision: 0x709
	LMP Version: 4.0 (0x6)  Subversion: 0x709
	Manufacturer: Cambridge Silicon Radio (10)

And it works fine--Ubuntu 16.04 for ARM. Usually, it's the ARM releases that have issues. I'll have to try 16.04 on an x64 system.

Chuck(G) · Mar 17, 2019

Tried 16.04 LTS on a x64 system--same as 14.04 and 18.04 LTS: squat.

ldkraemer · Mar 17, 2019

Chuck,
These instructions may help.

REF: https://askubuntu.com/questions/632336/bluetooth-broadcom-43142-isnt-working

Enter the following command to discover which driver name is the kernel looking for when loading the drives while booting:

Code:

dmesg | grep -i 'firmware load'

Try this one if it does not find anything:

Code:

dmesg | grep -i 'bluetooth'

The result should be something like this:

bluetooth hci0: Direct firmware load for brcm/BCM.hcd failed with error -2

Explanation: in my case the kernel is looking for the file BCM.hcd under the directory /lib/firmware/brcm where the Broadcom drivers are expected to be.
If the Kernel is looking for another driver name, you must rename the driver file (BCM43142A0-0a5c-216c.hcd in my case for the BCM43142 (0a5c:216d))
to the required name by the kernel.

Move the renamed driver (BCM.hcd) to your home directory (/home/YourUsername/) and run the following command in order to move it to the folder the kernel is looking on while booting:

Code:

sudo mv ~/BCM.hcd /lib/firmware/brcm

You must use the corresponding driver depending on your device and rename it if requested for the kernel.

The Broadcom drivers can be found at:
https://github.com/winterheart/broadcom-bt-firmware/tree/master/brcm

Reboot your computer and it should work!* (you can enter dmesg | grep -i 'bluetooth' once again to see if the driver has been loaded)

Larry

Chuck(G) · Mar 17, 2019

Figured it out--and without a kernel patch, it's not going to work on Ubuntu.

Basically, btmon tells the whole story:

Code:

HCI Event: Command Complete (0x0e) plen 6
    Delete Stored Link Key (0x03|0x0012) ncmd 5
    status 0x11 deleted 0
    Error: Unsupported Feature or Parameter Value

Yet, the device claims to support the command:

Code:

> HCI Event: Command Complete (0x0e) plen 68               #31 [hci0] 10.207958
      Read Local Supported Commands (0x04|0x0002) ncmd 5
        Status: Success (0x00)
        Commands: 165 entries
          Inquiry (Octet 0 - Bit 0)
          Inquiry Cancel (Octet 0 - Bit 1)
...
          Reset (Octet 5 - Bit 7)
          Set Event Filter (Octet 6 - Bit 0)
          Flush (Octet 6 - Bit 1)
          Read PIN Type (Octet 6 - Bit 2)
          Write PIN Type (Octet 6 - Bit 3)
          Create New Unit Key (Octet 6 - Bit 4)
          Read Stored Link Key (Octet 6 - Bit 5)
          Write Stored Link Key (Octet 6 - Bit 6)
          Delete Stored Link Key (Octet 6 - Bit 7)
          Write Local Name (Octet 7 - Bit 0)
          Read Local Name (Octet 7 - Bit 1)

Well, I could rebuild the kernel and simply ignore the "Delete Stored Link Key" result, which would probably work, but that would mean re-building on every system I have here. Easier to get some new dongles, I'm afraid.

Got any recommendations for cheap USB BT dongles that work?

Tor · Mar 18, 2019

BT dongles have always worked for me, in the past - every one of them. But I haven't used any lately (i.e. with newer kernels). So I tried one I found just now, and it works too, on my 4.12 kernel.
It looks like it may be the one in the left of the picture in your link though (mine is a Cambridge BT too), so I'm not sure how this helps.

(lsusb)
Bus 001 Device 083: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

(hciconfig -a)
hci1: Type: Primary Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:646 acl:0 sco:0 events:42 errors:0
TX bytes:2175 acl:0 sco:0 commands:42 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'BlueZ 5.47'
Class: 0x00010c
Service Classes: Unspecified
Device Class: Computer, Laptop
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)

On the dongle itself it's printed CSR 4.0

Chuck(G) · Apr 5, 2019

Got one of those dongles with "CSR 4.0" printed on it here. Same chip inside as before; fails the same way.

There is a check for a similar dongle that sets a "quirk" flag so that the stored link key commands are not issued. However, it's conditioned on the specific chip ID. The ones I've been testing are later.

Again, they work fine in Armbian and on Windows 7.

ldkraemer · Apr 6, 2019

Chuck,
I just set up my older HP Laptop with Debian 9.8 (64 Bit), and I have tried my Bluetooth Dongle (4.0) and here is what I get.
It tries to pair with my phone after I make my Laptop discoverable, so I know it is working.

Plug in the Bluetooth Dongle.

Code:

lsusb

Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Code:

hciconfig

hci0: Type: Primary Bus: USB
BD Address: 00:1B:DC:06:AF:21 ACL MTU: 310:10 SCO MTU: 64:8
DOWN
RX bytes:574 acl:0 sco:0 events:30 errors:0
TX bytes:368 acl:0 sco:0 commands:30 errors:0

Code:

APPLICATIONS ---> SETTINGS --> BLUETOOTH ADAPTERS

Turn ON Adapter, but Leave Hidden by using the Icon in the Top right of my Debian 9.8 Window.

Code:

hciconfig

hci0: Type: Primary Bus: USB
BD Address: 00:1B:DC:06:AF:21 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:1184 acl:0 sco:0 events:66 errors:0
TX bytes:1072 acl:0 sco:0 commands:66 errors:0

I then make my laptop discoverable, and my Smartphone will try to pair to the device, so I know it's working.

I have the following packages installed:

blueman 2.0.4-1
bluez 5.43-2+deb9u1
bluez-obexd 5.43-2+deb9u1
libbluetooth3 5.43-2+deb9u1

Larry

Chuck(G) · Apr 6, 2019

Larry,

My kernel is x64 4.15.0-47.

So I do an hciconfig:

Code:

hci0:	Type: Primary  Bus: USB
	BD Address: 33:03:30:0A:C4:A3  ACL MTU: 360:4  SCO MTU: 0:0
	DOWN 
	RX bytes:553 acl:0 sco:0 events:28 errors:0
	TX bytes:368 acl:0 sco:0 commands:30 errors:0

When I go to Applications->Settings->Bluetooth adapters, I get a blank window with just the "Close" dialog.

bluez: 5.50
blueman: 2.05
bluez-obexd 5.50
libbluetooth3 5.50

(all of the above are from the standard Ubuntu repository +0Ubuntu1)

Running hcidump in one window and doing "sudo hciconfig hci0 up" in another, I get the following trace:

Code:

~$ hcidump hci0
HCI sniffer - Bluetooth packet analyzer ver 5.50
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 12
    Read Local Supported Features (0x04|0x0003) ncmd 5
    status 0x00
    Features: 0xff 0xff 0xcd 0xfa 0xdb 0xbf 0x7b 0x87
> HCI Event: Command Complete (0x0e) plen 12
    Read Local Version Information (0x04|0x0001) ncmd 5
    status 0x00
    HCI Version: 4.0 (0x6) HCI Revision: 0x709
    LMP Version: 4.0 (0x6) LMP Subversion: 0x709
    Manufacturer: Cambridge Silicon Radio (10)
> HCI Event: Command Complete (0x0e) plen 10
    Read BD ADDR (0x04|0x0009) ncmd 5
    status 0x00 bdaddr 33:03:30:0A:C4:A3
> HCI Event: Command Complete (0x0e) plen 11
    Read Buffer Size (0x04|0x0005) ncmd 5
    status 0x00
    ACL MTU 360:4 SCO MTU 0:0
> HCI Event: Command Complete (0x0e) plen 7
    Read Class of Device (0x03|0x0023) ncmd 5
    status 0x00 class 0x000000
> HCI Event: Command Complete (0x0e) plen 252
    Read Local Name (0x03|0x0014) ncmd 5
    status 0x00 name ''
> HCI Event: Command Complete (0x0e) plen 6
    Read Voice Setting (0x03|0x0025) ncmd 5
    status 0x00 voice setting 0x0000
> HCI Event: Command Complete (0x0e) plen 5
    Read Number of Supported IAC (0x03|0x0038) ncmd 5
> HCI Event: Command Complete (0x0e) plen 8
    Read Current IAC LAP (0x03|0x0039) ncmd 5
    IAC 0x9e8b33 (General Inquiry Access Code)
> HCI Event: Command Complete (0x0e) plen 4
    Set Event Filter (0x03|0x0005) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 4
    Write Connection Accept Timeout (0x03|0x0016) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 7
    LE Read Buffer Size (0x08|0x0002) ncmd 5
    status 0x00 pktlen 0x001b maxpkt 0x12
> HCI Event: Command Complete (0x0e) plen 12
    LE Read Supported States (0x08|0x001c) ncmd 5
> HCI Event: Command Complete (0x0e) plen 68
    Read Local Supported Commands (0x04|0x0002) ncmd 5
    status 0x00
    Commands: bfffff03feffffff0fffff1ff20fe8fe3ff78fff1c00000061f7ffff7f18
> HCI Event: Command Complete (0x0e) plen 4
    Write Extended Inquiry Response (0x03|0x0052) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 4
    Write Inquiry Mode (0x03|0x0045) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 5
    Read Inquiry Response Transmit Power Level (0x03|0x0058) ncmd 5
    status 0x00 level 8
> HCI Event: Command Complete (0x0e) plen 14
    Read Local Extended Features (0x04|0x0004) ncmd 5
    status 0x00 page 1 max 0
    Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Complete (0x0e) plen 4
    Set Event Mask (0x03|0x0001) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 8
    Read Stored Link Key (0x03|0x000d) ncmd 5
    status 0x00 max 0 num 0
> HCI Event: Command Complete (0x0e) plen 4
    Write Default Link Policy Settings (0x02|0x000f) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 8
    Read Page Scan Activity (0x03|0x001b) ncmd 5
    status 0x00 interval 512 window 18
> HCI Event: Command Complete (0x0e) plen 5
    Read Page Scan Type (0x03|0x0046) ncmd 5
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Event Mask (0x08|0x0001) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 5
    LE Read White List Size (0x08|0x000f) ncmd 5
> HCI Event: Command Complete (0x0e) plen 4
    LE Clear White List (0x08|0x0010) ncmd 5
    status 0x00
> HCI Event: Command Complete (0x0e) plen 6
    Delete Stored Link Key (0x03|0x0012) ncmd 5
    status 0x11 deleted 0
    Error: Unsupported Feature or Parameter Value

I'll add that the same result is manifested when I use another BT dongle labeled "CSR 4.0" on a square-ish package. The only real difference is that it displays

Code:

 HCI Version: 4.0 (0x6) HCI Revision: 0x811
    LMP Version: 4.0 (0x6) LMP Subversion: 0x811
    Manufacturer: Cambridge Silicon Radio (10)

Chuck(G) · Apr 6, 2019

Oh, and here are the two dongles I tested:

ldkraemer · Apr 6, 2019

Chuck,
WOW! Looks like later versions break the Bluetooth code. I wonder if that will also creep into later versions of Debian?

Mine pairs, so I know it works on Debian 9.8 (64 Bit)

Larry

Chuck(G) · Apr 6, 2019

Well, FWIW, here's the relevant code in btusb.c:

Code:

/* Detect controllers which aren't real CSR ones. */
	if (le16_to_cpu(rp->manufacturer) != 10 ||
	    le16_to_cpu(rp->lmp_subver) == 0x0c5c) {
		/* Clear the reset quirk since this is not an actual
		 * early Bluetooth 1.1 device from CSR.
		 */
		clear_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks);

		/* These fake CSR controllers have all a broken
		 * stored link key handling and so just disable it.
		 */
		set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
	}

Note that it's an idiotic fix--it's tied specifically to LMP Subversion 0x0c5c. My samples show this subversion is all over the place. The more sensible fix would be to ignore the return from the call to "Delete Stored Link Key". I suppose I could submit a request to the Linux Kernel people, but I doubt I would get any quick action. I can change the code, recompile the kernel and fix it myself, but then I'll have to do that every time a new kernel comes out.

Chuck(G) · Apr 7, 2019

ldkraemer said:
Chuck,
WOW! Looks like later versions break the Bluetooth code. I wonder if that will also creep into later versions of Debian?

Mine pairs, so I know it works on Debian 9.8 (64 Bit)

Since most Linuces share the same kernel code, I suspect an error in Ubuntu's kernel will be the same on Debian's. Linus generally vets kernel mods.

Getting cheap BT dongle to work--Ubuntu64

Chuck(G)

25k Member

ldkraemer

Veteran Member

Chuck(G)

25k Member

Chuck(G)

25k Member

ldkraemer

Veteran Member

Chuck(G)

25k Member

Chuck(G)

25k Member

Chuck(G)

25k Member

Chuck(G)

25k Member

ldkraemer

Veteran Member

Chuck(G)

25k Member

Tor

Veteran Member

Chuck(G)

25k Member

ldkraemer

Veteran Member

Chuck(G)

25k Member

Chuck(G)

25k Member

ldkraemer

Veteran Member

Chuck(G)

25k Member

Chuck(G)

25k Member