Code stuck at 'client, address = server.accept()' (bluetooth) - bluetooth

I have connected a device by bluetooth to send data, but the code hangs at the statement:
client, address = server.accept()
This is the code
import bluetooth
#00:07:80:E0:A4:FC
host = ""
port = 1
server = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
print('Bluetooth Socket Created')
try:
server.bind((host, port))
print("Bluetooth Binding Completed")
except:
print("Bluetooth Binding Failed")
server.listen(1)
try:
client, address = server.accept()
print("Connected to: ", address)
print("Client: ", client)
except Exception as e:
print (str(e))
try:
while True:
data = client.recv(1)
print(data)
client.send(data)
except:
client.close()
server.close()
The device is connected:
When pairing the pwd from the sending device was requested.
When I do ctrl-c I get the following message:
Also: everything works fine
when connecting with an Android phone and using the serial BT app
systemctl status bluetooth:
sudo btmon:
Content of /etc/bluetooth/rfcomm.conf is:
rfcomm1 {
# Automatically bind the device at startup
bind yes;
# Bluetooth address of the device
device 00:07:80:E0:A4:FC
#xx:xx:xx:xx:xx:xx;
# RFCOMM channel for the connection
channel 1;
# Description of the connection
comment "Soehnle Bluetooth Connection";
}
Also the content of /lib/systemd/system/bluetooth.service:
[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
ConditionPathIsDirectory=/sys/class/bluetooth
[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluetooth/bluetoothd -C
ExecStartPost=/usr/bin/sdptool add SP
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1
ProtectHome=true
ProtectSystem=full
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
Bluetoothctl output as code:
WT11i-A]# info
Device 00:07:80:E0:A4:FC (public)
Name: WT11i-A
Alias: WT11i-A
Class: 0x00001f00
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Serial Port (00001101-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v0047pF000d0400
RFCOMM command output as code:
pi#raspberrypi:~ $ sudo rfcomm -a show hci0
rfcomm0: B8:27:EB:A6:D7:4F -> 00:07:80:E0:A4:FC channel 1 closed [reuse-dlc release-on-hup tty-attached]
rfcomm1: B8:27:EB:A6:D7:4F -> 00:07:80:E0:A4:FC channel 1 connected [reuse-dlc release-on-hup tty-attached]
ctrl-c output as code:
pi#raspberrypi:~ $ sudo python bluetoothtest4.py
Bluetooth Socket Created
Bluetooth Binding Completed
^CTraceback (most recent call last):
File "bluetoothtest4.py", line 18, in <module>
client, address = server.accept()
File "/usr/lib/python3/dist-packages/bluetooth/bluez.py", line 167, in accept
client, addr = self._sock.accept ()
KeyboardInterrupt
systemctl output as code:
pi#raspberrypi:~ $ systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-11-21 12:51:21 CET; 2 days ago
Docs: man:bluetoothd(8)
Main PID: 734 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 2059)
CGroup: /system.slice/bluetooth.service
└─734 /usr/lib/bluetooth/bluetoothd
Nov 21 12:51:21 raspberrypi bluetoothd[734]: Bluetooth daemon 5.50
Nov 21 12:51:21 raspberrypi systemd[1]: Started Bluetooth service.
Nov 21 12:51:21 raspberrypi bluetoothd[734]: Starting SDP server
Nov 21 12:51:21 raspberrypi bluetoothd[734]: Bluetooth management interface 1.18 initialized
Nov 21 12:51:21 raspberrypi bluetoothd[734]: Sap driver initialization failed.
Nov 21 12:51:21 raspberrypi bluetoothd[734]: sap-server: Operation not permitted (1)
Nov 21 12:51:21 raspberrypi bluetoothd[734]: Failed to set privacy: Rejected (0x0b)
Nov 21 12:51:23 raspberrypi bluetoothd[734]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSource
Nov 21 12:51:23 raspberrypi bluetoothd[734]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSink
Nov 23 11:36:42 raspberrypi systemd[1]: bluetooth.service: Current command vanished from the unit file, execution of the command list won't be resumed.
btmon output as code:
# RAW Open: blueman-manager version 2.22 {0x0004} 986.383469
# RAW Close: blueman-manager {0x0004} 986.383531
< HCI Command: Read RSSI (0x05|0x0005) plen 2 #5905 [hci0] 986.385681
Handle: 12
> HCI Event: Command Complete (0x0e) plen 7 #5906 [hci0] 986.386072
Read RSSI (0x05|0x0005) ncmd 1
Status: Success (0x00)
Handle: 12
RSSI: 0 dBm (0x00)
< HCI Command: Read Link Quality (0x05|0x0003) plen 2 #5907 [hci0] 986.386278
Handle: 12
> HCI Event: Command Complete (0x0e) plen 7 #5908 [hci0] 986.386591
Read Link Quality (0x05|0x0003) ncmd 1
Status: Success (0x00)
Handle: 12
Link quality: 0x8c
< HCI Command: Read Transmit Power Level (0x03|0x002d) plen 3 #5909 [hci0] 986.386755
Handle: 12
Type: Current Transmit Power Level (0x00)
> HCI Event: Command Complete (0x0e) plen 7 #5910 [hci0] 986.387069
Read Transmit Power Level (0x03|0x002d) ncmd 1
Status: Success (0x00)
Handle: 12
TX power: 12 dbm (0x0c)

I believe your main problem is you do not have a matching profile in your client with what your device (server) is offering.
BlueZ is the official Linux Bluetooth protocol stack which is based on D-Bus API. Hence, if you would like to build a solid python code, I suggest you to have a look at it.
The rfcoom tool is also deprecated, however it does still do the work.
The steps that work for me with rfcomm are:
bluetoothctl
scan on // wait until your device MAC appears
scan off
pair 00:07:80:E0:A4:FC
In this step it might ask for a pin, in my case I was using an Arduino as server, the default one was either 0000 or 1234. Then:
trust 00:07:80:E0:A4:FC // so you do not need to pair everytime
quit
Now we connect via:
sudo rfcomm connect hci0 00:07:80:E0:A4:FC
Replace hci0 with name of your own Bluetooth adapter.
For D-Bus example please see this discussion. #ukBaz provides nice explanation with an example code. You may need scanning if your device is not discovered, you can find that in my code and add it.

Related

Bluetooth connection failed from Raspberry Pi at LE Read Remote Used Features

I'm trying to pair a Raspberry Pi 4 model B with an Ortho remote, but it's failing to connect.
I'm using the Linux raspberrypi 5.10.17-v7l+ kernel
I'm still very new to debugging bluetooth, but it looks like it's failing at the "LE Read Remote Used Features" step, with an "Connection Failed to be Established (0x3e)" error. What does this mean? Anything I can do to debug this further?
$ sudo bluetoothctl
[bluetooth]# trust F9:XX:XX:XX:XX:XX
Changing F9:XX:XX:XX:XX:XX trust succeeded
[bluetooth]# connect F9:XX:XX:XX:XX:XX
Attempting to connect to F9:XX:XX:XX:XX:XX
[CHG] Device F9:XX:XX:XX:XX:XX Connected: yes
Failed to connect: org.bluez.Error.Failed
[CHG] Device F9:XX:XX:XX:XX:XX Connected: no
[bluetooth]# pair F9:XX:XX:XX:XX:XX
Attempting to pair with F9:XX:XX:XX:XX:XX
[CHG] Device F9:XX:XX:XX:XX:XX Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device F9:XX:XX:XX:XX:XX Connected: no
$ sudo btmon
...
# MGMT Event: Device Connected (0x000b) plen 44 {0x0002} [hci0] 1979.845117
LE Address: F9:XX:XX:XX:XX:XX (Static)
Flags: 0x00000000
Data length: 31
Name (complete): ortho remote
Flags: 0x04
BR/EDR Not Supported
Company: not assigned (1104)
Data: 01005238434b4931324b
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2 #1688 [hci0] 1979.845351
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #1689 [hci0] 1979.846487
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 14 #1690 [hci0] 1979.846501
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
00 00 00 00 00 00 00 00 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 12 #1691 [hci0] 1980.142018
LE Read Remote Used Features (0x04)
Status: Connection Failed to be Established (0x3e)
Handle: 64
Features: 0x3f 0x00 0x00 0x08 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
LE Data Packet Length Extension
Unknown features (0x0000000008000000)
# MGMT Event: Command Complete (0x0001) plen 10 {0x0001} [hci0] 1980.142093
Pair Device (0x0019) plen 7
Status: Failed (0x03)
LE Address: F9:XX:XX:XX:XX:XX (Static)
> HCI Event: Disconnect Complete (0x05) plen 4 #1692 [hci0] 1980.143150
Status: Success (0x00)
Handle: 64
Reason: Connection Failed to be Established (0x3e)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 1980.143206
LE Address: F9:XX:XX:XX:XX:XX (Static)
Reason: Unspecified (0x00)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 1980.143206
LE Address: F9:XX:XX:XX:XX:XX (Static)
Reason: Unspecified (0x00)
It seems like for some reason your Bluetooth mode was set to bredr, and because your device is a BLE device that does not support Bluetooth Classic -> BR/EDR Not Supported, you were not able to connect. Thus, setting it to dual does the trick. You can set it to dual mode via editing etc/bluetooth/main.conf. I would expect a same behaviour, if you set it to le as well.
# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
ControllerMode = dual

Debian: Bluetooth-scan not showing any results

I have an Asus VivoMini UN45, and can't get bluetooth to work right.
As far as I can tell, the HW is supported and the drivers are loaded (It's the Lite-On adapter shown on Bus 001 Device 002)
$ lsusb
Bus 002 Device 002: ID 0bc2:ab62 Seagate RSS LLC
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 04ca:17ea Lite-On Technology Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ hcitool dev
Devices:
hci0 30:52:CB:05:B9:6A
I can interact with the controller, and start discovery of devices
$ bluetoothctl
Agent registered
[bluetooth]# show
Controller 30:52:CB:05:B9:6A (public)
Name: lux
Alias: luxie
Class: 0x00000104
Powered: yes
Discoverable: yes
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0532
Discovering: yes
[bluetooth]# scan on
Discovery started
[bluetooth]#
But nothing more happens. The strange thing is I can see a lot of activity in btmon:
$ sudo btmon
Bluetooth monitor ver 5.50
= Note: Linux version 5.11.0-10.1-liquorix-amd64 (x86_64) 0.950933
= Note: Bluetooth subsystem version 2.22 0.950939
= New Index: 30:52:CB:05:B9:6A (Primary,USB,hci0) [hci0] 0.950941
= Open Index: 30:52:CB:05:B9:6A [hci0] 0.950941
= Index Info: 30:52:CB:05:B9:6A (Atheros Communications, Inc.) [hci0] 0.950942
# RAW Open: python3 version 2.22 {0x0002} [hci0] 0.950944
# MGMT Open: bluetoothd (privileged) version 1.19 {0x0001} 0.950945
# MGMT Open: btmon (privileged) version 1.19 {0x0003} 0.950993
> HCI Event: Inquiry Complete (0x01) plen 1 #1 [hci0] 10.556060
Status: Success (0x00)
# RAW Close: python3 {0x0002} [hci0] 10.556255
# RAW Open: python3 version 2.22 {0x0002} 10.557104
# RAW Close: python3 {0x0002} 10.557130
# RAW Open: python3 version 2.22 {0x0002} [hci0] 10.557165
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 #2 [hci0] 10.557219
Address: 8C:F1:12:A2:6C:BF (OUI 8C-F1-12)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
> HCI Event: Command Status (0x0f) plen 4 #3 [hci0] 10.560060
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
# RAW Close: python3 {0x0002} [hci0] 15.555375
# RAW Open: python3 version 2.22 {0x0002} 15.556323
# RAW Close: python3 {0x0002} 15.556358
# RAW Open: python3 version 2.22 {0x0002} [hci0] 15.556388
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 #4 [hci0] 15.556466
Address: E0:63:E5:EF:A9:52 (Sony Mobile Communications Inc)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
> HCI Event: Command Status (0x0f) plen 4 #5 [hci0] 15.557261
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Remote Name Req Complete (0x07) plen 255 #6 [hci0] 15.574193
Status: Memory Capacity Exceeded (0x07)
Address: E0:63:E5:EF:A9:52 (Sony Mobile Communications Inc)
Name: NoName
# RAW Close: python3 {0x0002} [hci0] 15.574370
# RAW Open: python3 version 2.22 {0x0002} 15.575566
# RAW Close: python3 {0x0002} 15.575603
# RAW Open: python3 version 2.22 {0x0002} [hci0] 15.575649
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 #7 [hci0] 15.575719
Address: 3C:01:EF:69:26:39 (Sony Mobile Communications Inc)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
> HCI Event: Command Status (0x0f) plen 4 #8 [hci0] 15.577235
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Remote Name Req Complete (0x07) plen 255 #9 [hci0] 15.594192
Status: Memory Capacity Exceeded (0x07)
Address: 3C:01:EF:69:26:39 (Sony Mobile Communications Inc)
Name: NoName
# RAW Close: python3 {0x0002} [hci0] 15.594334
# RAW Open: python3 version 2.22 {0x0002} 15.595407
# RAW Close: python3 {0x0002} 15.595431
# RAW Open: python3 version 2.22 {0x0002} [hci0] 15.595463
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 #10 [hci0] 15.595524
Address: E8:31:F3:6C:17:DA (OUI E8-31-F3)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
> HCI Event: Command Status (0x0f) plen 4 #11 [hci0] 15.596199
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Remote Name Req Complete (0x07) plen 255 #12 [hci0] 15.613228
Status: Memory Capacity Exceeded (0x07)
Address: E8:31:F3:6C:17:DA (OUI E8-31-F3)
Name: NoName
# RAW Close: python3
Running all of this as root makes no difference.
Any clues? Btmon gives errors like "Status: Memory Capacity Exceeded (0x07)" and "Status: Page Timeout (0x04)", but my Google-Fu is too weak to proceed.

Raspberry Pi bluetooth connection error: "Connection reset by peer"

Good day. I am trying connect bluetooth loudspeaker to Raspberry Pi (RP). I've successfully connected the bluetooth headset using:
sudo bluetoothctl
pair <Headphones' MAC Address>
connect <Headphones' MAC Address>
And everything is all right. But when I am trying connect to soundspeaker it is not.
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:15:83:15:A3:10 Discovering: yes
[NEW] Device F9:56:48:48:A6:8C 17979 speaker
[bluetooth]# pair F9:56:48:48:A6:8C
Attempting to pair with F9:56:48:48:A6:8C
[CHG] Device F9:56:48:48:A6:8C Connected: yes
[CHG] Device F9:56:48:48:A6:8C Connected: no
[CHG] Device F9:56:48:48:A6:8C Connected: yes
[CHG] Device F9:56:48:48:A6:8C Connected: no
[CHG] Device F9:56:48:48:A6:8C Paired: yes
Pairing successful
[bluetooth]# trust F9:56:48:48:A6:8C
[CHG] Device F9:56:48:48:A6:8C Trusted: yes
Changing F9:56:48:48:A6:8C trust succeeded
[bluetooth]# info F9:56:48:48:A6:8C
Device F9:56:48:48:A6:8C (public)
Name: 17979 speaker
Alias: 17979 speaker
Class: 0x00240418
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: yes
[bluetooth]# connect F9:56:48:48:A6:8C
Attempting to connect to F9:56:48:48:A6:8C
[CHG] Device F9:56:48:48:A6:8C Connected: yes
[CHG] Device F9:56:48:48:A6:8C Connected: no
[CHG] Device F9:56:48:48:A6:8C Connected: yes
[CHG] Device F9:56:48:48:A6:8C Connected: no
Failed to connect: org.bluez.Error.Failed
Here is result of journalctl: (I think, 2 last lines are important)
journalctl -u bluetooth | tail
Feb 27 22:52:58 raspberrypi bluetoothd[318]: F9:56:48:48:A6:8C: error updating services: Connection reset by peer (104)
Feb 27 22:54:57 raspberrypi bluetoothd[318]: F9:56:48:48:A6:8C: error updating services: Connection reset by peer (104)
Feb 27 22:59:16 raspberrypi bluetoothd[318]: Authentication attempt without agent
Feb 27 22:59:16 raspberrypi bluetoothd[318]: Hands-Free Voice gateway rejected 17:09:22:17:0D:31: org.bluez.Error.Rejected
Feb 27 23:00:17 raspberrypi bluetoothd[318]: Authentication attempt without agent
Feb 27 23:00:17 raspberrypi bluetoothd[318]: Hands-Free Voice gateway rejected 17:09:22:17:0D:31: org.bluez.Error.Rejected
Feb 27 23:00:51 raspberrypi bluetoothd[318]: /org/bluez/hci0/dev_17_09_22_17_0D_31/fd0: fd(25) ready
Feb 27 23:02:04 raspberrypi bluetoothd[318]: Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
Feb 27 23:34:39 raspberrypi bluetoothd[318]: F9:56:48:48:A6:8C: error updating services: Connection reset by peer (104)
Feb 27 23:35:48 raspberrypi bluetoothd[318]: F9:56:48:48:A6:8C: error updating services: Connection reset by peer (104)
What have I done wrong ? I'll appreciate any advice.

Bluetooth over uart using hciattach?

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

Bluetooth LE active scanning causes connection problems on other machine

I am having a problem where BLE active scanning on one machine causes connection problems on another machine. I was wounder if anyone could explain why, and offer any suggestions on how to fix.
I have broken down a rough version of my what my code does into simple scripts.
on machine 1:
sudo stdbuf -oL hcidump -X |tee hci.log &
sudo hcitool lewlclr
sudo hcitool lewladd 68:C9:0B:xx:xx:01
sudo hcitool lewladd 68:C9:0B:xx:xx:02
sudo hcitool lewladd 68:C9:0B:xx:xx:03
sudo hcitool lewladd 68:C9:0B:xx:xx:04
sudo hcitool lewladd 68:C9:0B:xx:xx:05
sudo hcitool lewladd 68:C9:0B:xx:xx:06
while true; do sudo hcitool lecc --whitelist; if [ $? == 1 ] ; then sleep 20; else sleep 1; sudo hcitool ledc 64 ; fi; done
The above will run with no problems
However after running the following on a different machine I get connection issues.
sudo hcitool lescan --duplicates
from the hci logs a normal connecition looks like:
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:00:00:00:00:00 type 0
interval 4 window 4 initiator_filter 1
own_bdaddr_type 0 min_interval 15 max_interval 15
latency 0 supervision_to 3200 min_ce 1 max_ce 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role master
bdaddr 68:C9:0B:xx:xx:xx (Public)
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 64 reason 0x13
Reason: Remote User Terminated Connection
> 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
and a bad connection is as follows:
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:00:00:00:00:00 type 0
interval 4 window 4 initiator_filter 1
own_bdaddr_type 0 min_interval 15 max_interval 15
latency 0 supervision_to 3200 min_ce 1 max_ce 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role master
bdaddr 68:C9:0B:xx:xx:xx (Public)
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x3e
Reason: Connection Failed to be Established
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 64 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x12 ncmd 1
Error: Invalid HCI Command Parameters
Note: the last two entries (Invalid HCI Command Parameters) are because of the crudeness of the script, and only occur because of the failed connection.
Of note, it looks like the connection is made, then it says in couldn't (Connection Failed to be Established). This seems a bit confusing to me.
I have tried this on different machines. (desktop PC and RPi3)
Peripheral is advertising. That means it periodically sends an avertisement (ADV_IND) packet on some advertisement channel. In response to this packet, a central may either (Core_v4.2, 6.B.4.4.2.3):
do nothing,
send a scan request (SCAN_REQ) packet (Figure 4.3), peripheral should respond with a scan response (SCAN_RSP),
send a connection request (CONN_REQ) packet (Figure 4.5).
Here, you have two centrals trying to reach the same peripheral at the same time. One is doing active scanning (#2 above), the other is initiating (#3 above). Unfortunately, both must send their packet at the exact same time, receiver gets jammed, and both scan request and connection request packets get lost.
There is no acknowledgement for connection requests. Initiator must to assume the advertiser received and accepted the connection request, create the connection speculatively, and possibly time out afterwards. That's why the fast termination feature pointed by bare_metal exists. In case the peripheral does not take the connection request, central should not wait forever.
LE Connection Complete event in your dumps just tell a Connection Request packet got sent, it does not tell it actually got received, processed or accepted by target.
on the confusion of connection created vs connection established please see the vol 6, Part B,section 4.5 from low energy specification (core 4.2). so it seems in the second instance the remote device didn't send any
data channel packet after CONNECT_REQ PDU. and in the second case if a disconnect is tried on a link which is not established , the controller will complain about invalid handle ( as there is no valid connection exist). To debug further you could enable Timing in hcidump which will confirm the failed to establish event is received by the host after Supervision Timeout.
"The Link Layer enters the Connection State when an initiator sends a
CONNECT_REQ PDU to an advertiser or an advertiser receives a
CONNECT_REQ PDU from an initiator.
After entering the Connection State, the connection is considered to be
created. The connection is not considered to be established at this point. A connection is only considered to be established once a data channel packet
has been received from the peer device. The only difference between A connection that is created and a connection that is established is the Link Layer connection supervision timeout value that is used"
"If the Link Layer connection supervision timer reaches 6 * connInterval before the connection is established (see Section 4.5), the connection shall be considered lost. This enables fast termination of connections that fail to establish"

Resources