Need to determine whether the central and peripheral devices (both running Bluetooth 5.0) are communicating via the faster LE 2M PHY bit rate.
The command I am sending via the hcitool:
sudo hcitool cmd 8 30 40 0
The response received:
01 30 20 01
The btmon output:
# RAW Open: hcitool (privileged) version 2.22 {0x0005} 3503.199467
# RAW Close: hcitool {0x0005} 3503.199506
# RAW Open: hcitool (privileged) version 2.22 {0x0005} [hci0] 3503.199594
< HCI Command: LE Read PHY (0x08|0x0030) plen 2 #11120 [hci0] 3503.200023
Handle: 64
> HCI Event: Command Complete (0x0e) plen 4 #11121 [hci0] 3503.200353
LE Read PHY (0x08|0x0030) ncmd 1
Status: Unknown HCI Command (0x01)
# RAW Close: hcitool
For some reason I am getting the Unknown HCI Command error when running this command on the RPi 4 which is set as the peripheral via bleno.
Am I doing something wrong? Are there preliminary steps I need to take before I can read and set the symbol rate?
More info:
< HCI Command: Read Local Ve.. (0x04|0x0001) plen 0 #3 [hci0] 42.465863
> HCI Event: Command Complete (0x0e) plen 12 #4 [hci0] 42.466325
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 315 (0x013b)
LMP version: Bluetooth 5.0 (0x09) - Subversion 24857 (0x6119)
Manufacturer: Cypress Semiconductor Corporation (305)
# RAW Close: hcitool {0x0003} [hci0] 42.466507
Related
I followed the tutorial from The Bluetooth Technology for Linux Developers Study Guide (I skipped the 5th guide because I'm doing a gatt server), and everything worked fine until I got to Handling Characteristic Writes.
(Also, I am using a Raspberry PI 4 Model B)
In nRF Connect I have the following in the logs:
Writing request to characteristic e95d93ee-251d-470a-a062-fa1922dfa9a8
Data written to e95d93ee-251d-470a-a062-fa1922dfa9a8, value: (0x)68-65-6C-6C-6F, "hello"
"hello" sent
so the data should have been sent.
sudo btmon gives the following:
> ACL Data RX: Handle 64 flags 0x02 dlen 14 #129 [hci0] 82.584227
ATT: Prepare Write Request (0x16) len 9
Handle: 0x0019
Offset: 0x0000
Data: 68656c6c6f
< ACL Data TX: Handle 64 flags 0x00 dlen 14 #130 [hci0] 82.585053
ATT: Prepare Write Response (0x17) len 9
Handle: 0x0019
Offset: 0x0000
Data: 68656c6c6f
> HCI Event: Number of Completed Packets (0x13) plen 5 #131 [hci0] 82.814773
Num handles: 1
Handle: 64
Count: 1
so the data was indeed received. Though I don't understand why it says Prepare Write Request instead of just Write Request.
bluetoothd with -nd flag and tail -f /var/log/syslog gives the following:
Jul 28 09:20:45 raspberrypi bluetoothd[820]: bluetoothd[820]: src/device.c:gatt_debug() (chan 0x1bb9dd0) ATT PDU received: 0x16
Jul 28 09:20:45 raspberrypi bluetoothd[820]: bluetoothd[820]: src/device.c:gatt_debug() Prep Write Req - handle: 0x0019
Jul 28 09:20:45 raspberrypi bluetoothd[820]: src/device.c:gatt_debug() (chan 0x1bb9dd0) ATT PDU received: 0x16
Jul 28 09:20:45 raspberrypi bluetoothd[820]: src/device.c:gatt_debug() Prep Write Req - handle: 0x0019
but there is no reaction using sudo dbus-monitor --system, and nothing either in the program output terminal.
Do you have any Idea where the problem might come from?
(I tried reinstalling nRF Connect twice already, so I think the problem is from somewhere in the Raspberry, but is it from bluez? from dbus? or somewhere else?)
After reinstalling bluez, and not solving anything, I tried with an old samsung tablet, and it works. So it appears my assumption was wrong and the problem could be from my phone.
I would like to disable the 'Filter duplicates' setting on bluetooth controller level with the HCI Command 'LE Set Scan Enable' using the D-Bus Interface of bluetoothd.
I already tried to set the 'DuplicateData' parameter from SetDiscoveryFilter(org.bluez.Adapter1), but according to btmon this doesn't change the value of 'Filter duplicates' for LE Set Scan Enable.
I also read the man pages for 'bluetoothd' and 'main.conf' with no success.
By contrast I found that a 'hcitool lescan --duplicates' does the trick.
Any pointers would be greatly appreciated!
One issue with scanning using bluez is that the current Linux kernel support always turns on de-duplication of advertisements. See this thread in the linux-bluetooth mailing list. - dhalbert's comment on GitHub
Even if you perform
sudo bluetoothctl
menu scan
duplicate-data on
or pass {"DuplicateData": true} to D-Bus API SetDiscoveryFilter(), kernel driver will always send the following HCI command when the scanning is started:
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
Using hcitool lescan --duplicates bypasses kernel interpretation of BT MGMT command and send proper HCI command (Filter duplicates: Disabled (0x00)).
My workaround, as explained in comment on GitHub is the following (source of hci_le_set_scan_enable command):
# This is executed every time after 'scan on' is executed in bluetoothctl.
# First, disable ongoing scan enabled by bluetoothctl - if this is not executed
# then next command to enable scanning will result in Command Disallowed (0x0c)
# status. Fortunatelly, bluetoothctl seems not to be bothered by execution of
# this commands.
hcitool cmd 0x08 0x000C 0x00 0x00
# This results in
# < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
# Scanning: Disabled (0x00)
# Filter duplicates: Disabled (0x00)
# > HCI Event: Command Complete (0x0e) plen 4
# LE Set Scan Enable (0x08|0x000c) ncmd 1
# Status: Success (0x00)
# Now, enable scanning with duplicate filtering disabled
hcitool cmd 0x08 0x000C 0x01 0x00
# This results in
# < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
# Scanning: Enabled (0x01)
# Filter duplicates: Disabled (0x00)
# > HCI Event: Command Complete (0x0e) plen 4
# LE Set Scan Enable (0x08|0x000c) ncmd 1
# Status: Success (0x00)
# and bluetoothctl now reports all packets, as if the 'duplicate-data on'
# actually works as expected. Note: 'duplicate-data on' shall still be
# executed to prevent additional layer of filtering in bluetoothd itself.
For other workaround using hcitool lescan --duplicates + hciump, check Adafruit_Blinka_bleio.
Note, however, that both workarounds require elevated privileges.
Thank you very much for your answer. I tried the bluetoothctl command on
bluez 5.48 and 5.50 and get the same result as with my D-Bus application.
Regardless of the 'duplicate-data' setting (on/off), btmon/HCI always
shows 'Filter duplicates: Enabled' on 'scan on'
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #5 [hci0] 10.895438
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 10.898311
LE Set Scan Enable (0x08|0x000c) ncmd 2
Status: Success (0x00)
What really puzzles me is that disabling LE scan ('scan off') also disables
filter duplicates ... :-(
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #21 [hci0] 14.969999
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #22 [hci0] 14.973667
LE Set Scan Enable (0x08|0x000c) ncmd 2
Status: Success (0x00)
After reading doc/adapter-api.txt several times I assume that 'DuplicateData'
filter is meant to apply to bluez itself and not to the Bluetooth hardware,
but I might be wrong
Welcome to StackOverflow. When posting questions, it is very useful to post the version of the software and hardware used as this can help you get a better answer.
Regarding your question, this depends on the version of BlueZ you're using. Assuming that this is the current latest version (v5.50), then there is an option for Low Energy scanning to disable duplicating filters. Please have a look at the documentation here:-
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n107
You can also view this being used in the bluetoothctl command. Please have a look at this:-
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/client/main.c#n1390
If you want to try this out, you can use the bluetoothctl command as follows:-
#bluetoothctl
[bluetoothctl] menu scan
[bluetoothctl] duplicate-data on
[bluetoothctl] back
[bluetoothctl] scan on
This will return the adverts only once and duplicate adverts will be suppressed.
I hope this helps.
Currently using on OH1 Heart rate sensor (tiny.cc/mom03y)
I'm looking to subscribe to HR notification using bluepy. I have got the notifications working but the OH1 device disconnects after about 20-30secs in both bluepy and gatttool (remote user terminated) but not in bluetoothctl.
Looking for a reason why the connection stays alive in bluetoothctl and not in bluepy or gatttool, code and hcidump below, using bluez 5.50 and bluepy 1.30 on rasbian 4.14.
Bluepy
#packet count
packets = 0
class hrCallback(btle.DefaultDelegate):
def __init__(self):
btle.DefaultDelegate.__init__(self)
def handleNotification(self, cHandle, data):
global packets
packets += 1
print("packet: %s Handle: %s HR (bpm): %s " % (packets, cHandle, data[1]))
#connect to OH1
mac = "a0:9e:1a:4f:ef:8b"
oh1 = btle.Peripheral( mac )
oh1.setDelegate( hrCallback() )
#start hr notification
oh1.writeCharacteristic(38, b"\x01\x00", True)
#listen for notifications
while True:
try:
if oh1.waitForNotifications(1.0):
continue
except btle.BTLEDisconnectError:
pass
hcidump
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Parameters (0x08|0x000b) ncmd 1
status 0x00
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: Command Status (0x0f) plen 4
LE Read Remote Used Features (0x08|0x0016) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x13
Reason: Remote User Terminated Connection
Which version of BlueZ are you using? several tools (e.g. gatttool, hcitool, hciconfig) was deprecated and replaced by bluetoothctl and btmgmt, and the recommendation from the BlueZ team is to use the new tools instead. Please have a look at the following link:-
Deprecated BlueZ Tools
The difference between the new tools and the old tools is that the old tools were able of interfacing directly with the kernel, whereas the new tools perform operations by interfacing with D-Bus instead.
Therefore, the recommendation is always to use bluetoothctl as old tools are not maintained and this is likely why you are seeing the issue.
I'm attempting to connect a bluez peripheral to an iOS device; it's not working.
Please find below logs on peripheral side. I'm advertising using hciconfig hci0 leadv but I don't see any "Connect" option on Scanner applications on phone. Also bluez-4.101 doesn't have hciconfig hci0 leadv0 option to make it connectable.
With the same device acting as a Central I am able to make LE connections with other BLE devices, so that confirms kernel LE support and device is fine, only some bluez issues I assume are there.
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 1025, role slave
bdaddr 67:5D:F6:87:3D:2C (Random)
> ACL data: handle 1025 flags 0x02 dlen 7
ATT: MTU req (0x02)
client rx mtu 158
> ACL data: handle 1025 flags 0x02 dlen 27
> ACL data: handle 1025 flags 0x01 dlen 27
> ACL data: handle 1025 flags 0x01 dlen 9
L2CAP(d): cid 0x003a len 59 [psm 0]
0000: .9......com.appl
0010: e.BT.TS."....com
0020: .apple.BTLEServe
0030: r.classic..
> ACL data: handle 1025 flags 0x02 dlen 11
L2CAP(d): cid 0x003a len 7 [psm 0]
0000: ......
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1025 reason 0x13
Reason: Remote User Terminated Connection
How can I get this peripheral to connect?
Upgrading to the latest BlueZ version will solve the GATT related issues.
Quote from the linked page:
The 2.x , 3.x and 4.x series of libraries and packages are deprecated and not supported anymore by BlueZ developers. If you are using them please update to the 5.x series. The download link is only provided for reference.
This problem only occurs after I updated to Bluez-5.20+ (or maybe earlier)
I compiled Bluez with maintainer mode and experimental to get gatt-example included in the service list, and enabled the advertisement via hciconfig.
Every time I connect with iOS (with app like LightBlue, etc.), I got disconnected after this event :
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 48449.282018
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
Peer address type: Random (0x01)
Peer address: 7A:A0:D6:50:69:CE (Resolvable)
Connection interval: 30.00 msec (0x0018)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 720 msec (0x0048)
Master clock accuracy: 0x05
# Device Connected: 7A:A0:D6:50:69:CE (2) flags 0x0000
> HCI Event: LE Meta Event (0x3e) plen 13 [hci0] 48449.356021
LE Long Term Key Request (0x05)
Handle: 64
Random number: be7ee4252ef5d67f
Encryption diversifier: 0x57f5
< HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18 [hci0] 48449.356058
Handle: 64
Long term key: 696469e1eaa559f7707643bf410ab39b
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 48449.357019
LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
Status: Success (0x00)
Handle: 64
> HCI Event: Encryption Change (0x08) plen 4 [hci0] 48449.506019
Status: Success (0x00)
Handle: 64
Encryption: Enabled with AES-CCM (0x01)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 [hci0] 48449.594893
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 158
< HCI Command: Disconnect (0x01|0x0006) plen 3 [hci0] 48453.289196
Handle: 64
Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 48453.289992
Disconnect (0x01|0x0006) ncmd 1
Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 48453.345991
Status: Success (0x00)
Handle: 64
Reason: Connection Terminated By Local Host (0x16)
And bluetoothd debug log :
bluetoothd[3381]: src/adapter.c:resume_discovery()
bluetoothd[3381]: src/adapter.c:connected_callback() hci0 device 7A:A0:D6:50:69:CE connected eir_len 0
bluetoothd[3381]: src/device.c:device_create() dst 7A:A0:D6:50:69:CE
bluetoothd[3381]: src/device.c:device_new() address 7A:A0:D6:50:69:CE
bluetoothd[3381]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_7A_A0_D6_50_69_CE
bluetoothd[3381]: src/attrib-server.c:connect_event()
bluetoothd[3381]: src/device.c:device_create() dst 7A:A0:D6:50:69:CE
bluetoothd[3381]: src/device.c:device_new() address 7A:A0:D6:50:69:CE
bluetoothd[3381]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_7A_A0_D6_50_69_CE
bluetoothd[3381]: Unable to register device interface for 7A:A0:D6:50:69:CE
bluetoothd[3381]: src/device.c:device_free() 0x11dd220
bluetoothd[3381]: src/adapter.c:dev_disconnected() Device 7A:A0:D6:50:69:CE disconnected, reason 2
bluetoothd[3381]: src/adapter.c:adapter_remove_connection()
bluetoothd[3381]: src/adapter.c:adapter_remove_connection() Removing temporary device /org/bluez/hci0/dev_7A_A0_D6_50_69_CE
bluetoothd[3381]: src/device.c:device_remove() Removing device /org/bluez/hci0/dev_7A_A0_D6_50_69_CE
bluetoothd[3381]: src/device.c:btd_device_unref() Freeing device /org/bluez/hci0/dev_7A_A0_D6_50_69_CE
bluetoothd[3381]: src/device.c:device_free() 0x11e9720
bluetoothd[3381]: plugins/policy.c:disconnect_cb() reason 2
Any possible explanation to this?