I am using QN9021 SoC working in controller mode (BLE Bluetooth core specification v4.0). It supports some standard HCI commands as well as some vendor specific commands. I am trying to attach it in my ubuntu laptop.
The command that i have used is hciattach.
hciattach -s 9600 /dev/ttyUSBx any 9600 noflow nosleep
The hcidump shows while executing sudo hciconfig hci1 up.
HCI sniffer - Bluetooth packet analyzer ver 5.37
device: hci1 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Command Complete (0x0e) plen 12
Read Local Supported Features (0x04|0x0003) ncmd 11
status 0x00
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 11
status 0x00
HCI Version: 4.0 (0x6) HCI Revision: 0x400
LMP Version: 4.0 (0x6) LMP Subversion: 0x400
Manufacturer: Quintic Corp. (142)
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 11
status 0x00 bdaddr 08:7C:BE:3E:34:BB
> HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 11
status 0x00
ACL MTU 0:0 SCO MTU 0:0
> HCI Event: Command Complete (0x0e) plen 4
Read Class of Device (0x03|0x0023) ncmd 11
status 0x01 class 0x000000
Error: Unknown HCI Command
The hciconfig command shows:
hci1: Type: BR/EDR Bus: UART
BD Address: 08:7C:BE:3E:34:BB ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:192 acl:0 sco:0 events:15 errors:0
TX bytes:60 acl:0 sco:0 commands:15 errors:0
hci0: Type: BR/EDR Bus: USB
BD Address: C4:8E:8F:66:3B:0E ACL MTU: 820:8 SCO MTU: 255:16
UP RUNNING PSCAN
RX bytes:2457 acl:0 sco:0 events:196 errors:0
TX bytes:24646 acl:0 sco:0 commands:196 errors:0
I would like to know how to prevent the kernel or some bluetooth kernel module to send non-supported HCI commands. Do i need to patch linux kernel source code or write a module for my SoC.
Note:- Changing the SoC or writing firmware for it to support all necessary commands is not possible for this project.
EDIT:
I know the list of HCIcommand supported by my SoC. I am thinking of creating a module to tell the kernel and daemons running to send only supported commands to the SoC. I have a look at linux kernel source (specifically at this hci_core.c). I think modifying it may solve the problem after going through this link. In this link, some developer has provided a patch to support a bluetooth dongle. The patch prevents the hci_core.c file to send a specific HCI command to a dongle of a particular manufacturer.
All i want is suggestion to resolve this problem. Do i need to modify the linux kernel or write a module for my SoC?
NOTE:- The application will run on openwrt linux.
Okay, today we found out the solution:
# hciattach -r /dev/ttyS0 bcsp 115200
Maybe it helps somebody
Helpful Tips:May this link will be helps to you.
I will give two links for more details
and for bluetooth click here
and for kernel configuration click here
I have solved this problem few years back. I was using Linux version 4.4.14 and Bluez stack 5.38. Looks like QN9021 had some bugs. The problem wasn't with Read Class of Device but with the response given by QN9021 for the command: Read Local Supported Features. Since, it's the BLE controller chip, it shouldn't be sending Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 as the response to the above command.
The issue is kernel detects it as Classic Bluetooth controller chip and then sends non-supported HCI commands to the chip. The chip should have set the 5th and 6th bits (LMP_NO_BREDR and LMP_LE bits) of the 4th byte in the Features to the command Read Local Supported Features and then kernel detects it as a BLE controller mode chip and won't send any unsupported commands to a ble controller mode chip.
Since, I can't change the firmware of the chip, I had to patch the kernel.
Here are my patches:
*** hci_event.c 2017-02-10 00:05:13.149974000 +0530
--- bluetooth/hci_event.c 2016-06-24 22:48:38.000000000 +0530
***************
*** 588,597 ****
if (rp->status)
return;
-
memcpy(hdev->features, rp->features, 8);
- hdev->features[0][4] |= LMP_NO_BREDR;
- hdev->features[0][4] |= LMP_LE;
/* Adjust default settings according to features
* supported by device. */
--- 588,594 ----
I have also tired the following command but it didn't helped:
hciattach -r /dev/ttyS0 bcsp 115200
Related
We are working to use external Bluetooth device though BlueZ 5.49 and HCI-UART.
After using btattach or hciattach , we use the hciconfig to check the device status but the device always show DOWN.
The log as bellowing:
# hciattach -b /dev/ttyS1 any 1000000
Device setup complete
#
# hciconfig hci0 up
Can't init device hci0: Cannot assign requested address (99)
#
#hci0: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 27:7 SCO MTU: 0:0
DOWN
RX bytes:231 acl:0 sco:0 events:16 errors:0
TX bytes:88 acl:0 sco:0 commands:16 errors:0
We use btmon to check hci command and the command was workable but the last HCI command was Set_Event_Mask_Page2. I checked several times and the result was always the same.
Does some one have such kind of experience ? or can suggest me which part I can look into??
Linux Kenerl :4.9.89-1.6,
BlueZ: 5.49
I am running a buildroot-generated linux image (kernel 4.11.2) on a nanopi NEO air board, and I struggle to connect to my ruwido remote control.
I can see it when I scan the devices using hcitool :
# hcitool lescan
LE Scan ...
<snip>
5C:F8:21:85:8E:67 ruwido
<snip>
But I cannot get a connection (it acts like the remote is not here) :
# hcitool cc 5C:F8:21:85:8E:67
Can't create connection: Input/output error
The only thing I can do is get some information about it :
# hcitool leinfo 5C:F8:21:85:8E:67
Requesting information ...
Handle: 64 (0x0040)
LMP Version: 4.0 (0x6) LMP Subversion: 0x140
Manufacturer: Texas Instruments Inc. (13)
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
I also cannot use bluetoothctl since it doesn't detect my interface, even though it's initialized, bluetoothd is running and the modules are loaded :
# lsmod
Module Size Used by
bnep 20480 2
hci_uart 61440 1
btbcm 16384 1 hci_uart
btqca 16384 1 hci_uart
btintel 16384 1 hci_uart
bluetooth 348160 12 hci_uart,btintel,btqca,bnep,btbcm
brcmfmac 245760 0
brcmutil 16384 1 brcmfmac
sunxi_cir 16384 0
# ps -e | grep bluetooth
553 root /usr/sbin/bluetoothd
731 root grep bluetooth
# sudo hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: F7:93:3E:74:CF:62 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:12593 acl:7 sco:0 events:292 errors:0
TX bytes:2050 acl:4 sco:0 commands:155 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'NanoPi-NEO-Air'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x0
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
# bluetoothctl
Agent registered
[bluetooth]# power on
No default controller available
My question is, how do I get the remote paired and connected to the board ? It doesn't matter if it's through hcitool, bluetoothctl or another tool.
Update
Thanks to Prabhakar Lad's comment, bluetoothctl is now detecting the interface, however the problem still remains and the problem seems to have narrowed :
# rfkill unblock all
# hciconfig hci0 up
# hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: AA:AA:AA:AA:AA:AA ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:1930 acl:0 sco:0 events:101 errors:0
TX bytes:1587 acl:0 sco:0 commands:103 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'BlueZ 5.47'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x0
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
# bluetoothctl
[NEW] Controller F7:93:3E:74:CF:62 BlueZ 5.47 [default]
[NEW] Device 5C:F8:21:85:8E:67 ruwido
Agent registered
[bluetooth]# agent on
Agent is already registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Discovery started
[CHG] Controller F7:93:3E:74:CF:62 Discovering: yes
<snip>
[NEW] Device 5C:F8:21:85:8E:67 ruwido
<snip>
[bluetooth]# scan off
<snip>
[CHG] Device 5C:F8:21:85:8E:67 RSSI is nil
<snip>
[CHG] Controller F7:93:3E:74:CF:62 Discovering: no
Discovery stopped
[bluetooth]# pair 5C:F8:21:85:8E:67
Attempting to pair with 5C:F8:21:85:8E:67
[CHG] Device 5C:F8:21:85:8E:67 Connected: yes
[ruwido]# [ 501.424858] Bluetooth: hci0 unexpected SMP command 0x0b from 5c:f8:21:85:8e:67
[CHG] Device 5C:F8:21:85:8E:67 Connected: no
[bluetooth]# pair 5C:F8:21:85:8E:67
Attempting to pair with 5C:F8:21:85:8E:67
Failed to pair: org.bluez.Error.ConnectionAttemptFailed
The SMP error seems to be related to bluetooth low-energy security, so am I supposed to use a different tool for pairing ?
Additional information
I actually use the busybox init system with bluetooth init scripts I found in the manufacturer's image (which is nanopi-neo-air_FriendlyCore-Xenial_4.11.2_20171113.img) and adapted so that they could be used with busybox init (the init system on the image is systemd/upstart).
So I have two files :
/etc/init.d/S35brcm_patchram_plus : patches firmware (the card uses an AMPAK ap6212 bluetooth/wifi combo module)
/etc/init.d/S38bluetooth : starts bluetoothd
I use bluez 5.47 with the following options in buildroot 2017.08.1 :
BR2_PACKAGE_BLUEZ_TOOLS=y
# BR2_PACKAGE_BLUEZ_UTILS is not set
BR2_PACKAGE_BLUEZ5_UTILS=y
BR2_PACKAGE_BLUEZ5_UTILS_OBEX=y
BR2_PACKAGE_BLUEZ5_UTILS_CLIENT=y
BR2_PACKAGE_BLUEZ5_UTILS_DEPRECATED=y
# BR2_PACKAGE_BLUEZ5_UTILS_EXPERIMENTAL is not set
# BR2_PACKAGE_BLUEZ5_PLUGINS_HEALTH is not set
# BR2_PACKAGE_BLUEZ5_PLUGINS_MIDI is not set
# BR2_PACKAGE_BLUEZ5_PLUGINS_NFC is not set
# BR2_PACKAGE_BLUEZ5_PLUGINS_SAP is not set
BR2_PACKAGE_BLUEZ5_UTILS_TEST=y
# BR2_PACKAGE_BLUEZ5_UTILS_GATTTOOL is not set
You didnt go through my complete post, you need to perform following
steps after you have done with rfkill and service restart:
a] bluetoothctl
Start the tool, this should detect the controller
b] [bluetooth]# agent on
Turn on the pairing agent
c] [bluetooth]# scan on
Let bluez detect your device, look in my post it should print you baddr (5C:F8:21:85:8E:67)
d] [bluetooth]# scan off
Turn off scanning once your device is discovered
e] [bluetooth]# pair 5C:F8:21:85:8E:67
Now pair to the device
It should now be paired.
Note: you cannot pair a device until the bluez has scanned it.
Can't make my bluetooth work on Ubuntu.
The toggle is active.But it means nothing. Since system is not reacting on it
rfkill list output is normal:
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
hciconfig -a gives the following info
hci0: Type: Primary Bus: USB
BD Address: 9C:D2:1E:0D:2F:B2 ACL MTU: 1021:4 SCO MTU: 128:2
DOWN
RX bytes:1160 acl:0 sco:0 events:62 errors:0
TX bytes:742 acl:0 sco:0 commands:62 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
Typping of sudo hciconfig hci0 up results in:
Can't init device hci0: Invalid request code (56)
The output of hcitool dev command is empty:
Devices:
This is hcitool scan output
Device is not available: No such device
I seached for similar problems, checked their solutions if it works in my case, but failed - nothing has helped me. So I've decided to ask it here
There may be another usefull information which is not given here for now. But I don't know yet what should be provided in order to make the problem be solved easier.
Download the driver for the Mediatek MT7630E wireless card here
https://community.linuxmint.com/tutorial/view/1796
and execute the commands to compile and install the driver.
If wifi works after installing the driver but bluetooth doesn't, you should check "Readme.md" in driver file directory (/Downloads/MT7630E-release).
It worked for me in Linux Mint 18.3. Both wifi and bluetooth. But wifi only at 2.4GHz
I'm trying to connect a bluetooth low energy Oximeter with my Ubuntu desktop but I'm running into some problems.
I can see the device just fine by using hcitool lescan but I cannot connect when I type
sudo gatttool -b 00:1C:05:FF:ED:A9 -I
[ ][00:1C:05:FF:ED:A9][LE]> connect
These are the logs from hcidump -X:
HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) status 0x00 ncmd 1
HCI Event: Encrypt Change (0x08) plen 4
status 0x06 handle 64 encrypt 0x00
Error: PIN or Key Missing
HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x16
Reason: Connection Terminated by Local Host
This looks like some kind of authentication failure. The problem is that the oximeter doesn't require any PINs or passkeys. It's just a simple agent that sends data to whoever its connected.
Thank you
Try using the hcitool lecc command:
sudo hcitool lecc 00:1C:05:FF:ED:A9
I'm also facing the same problem with my oximeter. I haven't gotten to the bottom of it yet but I do have a workaround for my case. YMMV.
In my case, the connection works ok for the first few times and then stops working with the same PIN error you have shown. My workaround is to delete the pairing with the oximiter (which was created by the initially successful connects). I do this via "bt-device -r XX:XX:XX:XX:XX:XX". After that the connection succeeds. That is, need to delete any prior pairing before connecting again.
That's the short answer :-) Here's the research in more detail.
If you run hcidump as root (sudo hcidump -X) it will give you more verbose data. What you might see is this:
> ACL data: handle 69 flags 0x02 dlen 6
SMP: Security Request (0x0b)
auth req 0x00
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
0000: 45 00 ec 8e 25 1b 09 46 b3 f7 7e ae 20 be 0c 63 E...%..F..~. ..c
0010: fc cf ef e5 82 61 e0 eb d4 bd 54 f6 .....a....T.
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) status 0x00 ncmd 0
> HCI Event: Command Status (0x0f) plen 4
Unknown (0x00|0x0000) status 0x00 ncmd 1
> HCI Event: Encrypt Change (0x08) plen 4
status 0x06 handle 69 encrypt 0x00
Error: PIN or Key Missing
Looks to me like the oximiter requests a pairing (the first ACL data dump) but bluez does not initiate one like it is supposed to. Compare this with the initial successful connect. The oximiter requests a pairing and at that point the local bluez does respond with a pair request:
> ACL data: handle 70 flags 0x02 dlen 6
SMP: Security Request (0x0b)
auth req 0x00
< ACL data: handle 70 flags 0x00 dlen 11
SMP: Pairing Request (0x01)
capability 0x03 oob 0x00 auth req 0x01
max key size 0x10 init key dist 0x00 resp key dist 0x01
Capability: NoInputNoOutput (OOB data not present)
Authentication: Bonding (No MITM Protection)
Initiator Key Distribution:
Responder Key Distribution: LTK
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 70 packets 1
> ACL data: handle 70 flags 0x02 dlen 11
SMP: Pairing Response (0x02)
capability 0x03 oob 0x00 auth req 0x01
max key size 0x10 init key dist 0x00 resp key dist 0x01
Capability: NoInputNoOutput (OOB data not present)
Authentication: Bonding (No MITM Protection)
Initiator Key Distribution:
Responder Key Distribution: LTK
I'm still investigating to try and determine whether this is a bug in bluez or whether its user error on my part.
Try:
sudo gatttool -t random -b 00:1C:05:FF:ED:A9 -I
then type connect
I have two Bluetooth adapters, an old internal adapter and a new Bluetooth 4.0 adapter.
I am writing an application that uses a socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP) to connect to a Bluetooth LE device on Linux. When I call connect() with a sockaddr_l2 {.l2_family = AF_BLUETOOTH, .l2_bdaddr = {...}, .l2_cid = L2CAP_CID_ATT, .l2_bdaddr_type = BRADDR_LE_PUBLIC}, connect fails with errno=0x38000000=939524096 Unknown error, because Linux arbitrarily chooses the old adapter that only supports Bluetooth 2.1, not Bluetooth 4.0. The solution is to bind the socket to the bd_addr of the adapter that supports Bluetooth 4.0.
Question: How to tell which adapter is the Bluetooth 4.0 adapter? hciconfig does not tell which one is the one to use; they both say BR/EDR and not LE.
$ hciconfig
hci1: Type: BR/EDR Bus: USB
BD Address: 00:25:00:F6:97:F0 ACL MTU: 1021:5 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:1074 acl:0 sco:0 events:56 errors:0
TX bytes:1462 acl:0 sco:0 commands:56 errors:0
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:D6:A0:BF ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:146505 acl:328 sco:0 events:4189 errors:0
TX bytes:6213 acl:215 sco:0 commands:83 errors:0
$ modinfo bluetooth | grep ^version:
version: 2.17
$ modinfo btusb | grep ^version:
version: 0.6
$ lsb_release --description
Description: Ubuntu 14.04.1 LTS
$ uname --kernel-release
3.13.0-40-generic
To answer your question there is btmgmt info which will list the HCI version (on the same line as addr), you will have to look into Host Controller Interface Assigned numbers for the meaning of the numbers, version 6 below mean Bluetooth 4.0.
# btmgmt info
hci0: Primary controller
addr 5C:F3:70:XX:XX:XX version 6 manufacturer 15 class 0x1c010c
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy configuration static-addr
current settings: powered bondable ssp br/edr le secure-conn
name BlueZ 5.47
short name
If you need to know if the adapter support LE, you will have to look for le in Supported settings: because LE is not mandatory in bluetooth 4.0/4.1.
Try: hciconfig hci[0|1] version