Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LE Set Extended Scan Parameters on Raspberry PI / Raspian, bluez 5.50 #63

Open
matzrh opened this issue Feb 16, 2021 · 6 comments
Open

Comments

@matzrh
Copy link

matzrh commented Feb 16, 2021

First, I want to apologize for posting this here, but I could not find any good resources for BLE issues on bluez 5.5, Raspian etc.
I made the app work with a "hack" in the code in scanner.py and changed
self.hci_version = self.get_hci_version() to self.hci_version = 8 #self.get_hci_version(), thus tricking the code into believing I am running bluetooth version 4.8.

If I reverse it to the original (correct) version, I get in btmon the following errors

> HCI Event: Command Complete (0x0e) plen 4                                                                                                        
      LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
        Status: Unknown HCI Command (0x01)
....
> HCI Event: Command Complete (0x0e) plen 4                                                                                                        
      LE Set Extended Scan Enable (0x08|0x0042) ncmd 1
        Status: Unknown HCI Command (0x01)
....

Question: Do I need to enable something special to make the extended commands work, start bluetoothd with a special option?

hardware: Raspberry PI 4B, supposedly BT 5 enabled. Kernel 5.10.11-v7l+, Python 3.7.3
edit: my result for hciconfig -a:

hci0:	Type: Primary  Bus: UART
BD Address: DC:A6:32:F4:13:4F  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING PSCAN 
RX bytes:668819 acl:793 sco:0 events:66903 errors:0
TX bytes:104635086 acl:122991 sco:0 commands:901 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: 'rpi4b'
Class: 0x0c0000
Service Classes: Rendering, Capturing
Device Class: Miscellaneous, 
HCI Version: 5.0 (0x9)  Revision: 0x156
LMP Version: 5.0 (0x9)  Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
@idaniel86
Copy link
Contributor

This is sadly due to BT 5.0 commands being supported from bluez version 5.51, have a look https://github.com/bluez/bluez/blob/6de4bdb957cdc85d89851420ab06ca8e226f8d4e/emulator/btdev.c#L415

@mrts
Copy link

mrts commented Jun 12, 2021

This is sadly due to BT 5.0 commands being supported from bluez version 5.51, have a look https://github.com/bluez/bluez/blob/6de4bdb957cdc85d89851420ab06ca8e226f8d4e/emulator/btdev.c#L415

@idaniel86, did you mean that BT 5.0 commands are not supported in bluez version 5.51? Can you please explain the issue in a bit more detail?

@idaniel86
Copy link
Contributor

@mrts I am saying that they are supported from bluez version 5.51 and are not supported in version 5.50 as is mentioned in the description of the issue.

@mrts
Copy link

mrts commented Jun 16, 2021

Ah, right, now I see. @matzrh, perhaps you can try to upgrade bluez from 5.50 to 5.51 and see if this fixes the issue?

@mrts
Copy link

mrts commented Jun 23, 2021

@idaniel86, I tested with Bluez 5.53 on Ubuntu 20.04 for Raspberry Pi 4, no luck and beacontools seemed to interfere with WiFi: I had a SSH connection open to Pi and after beacontools scan the commands started to lag and the connection sometimes even dropped. Can this be related to bowdentheo/BLE-Beacon-Scanner#9 ?

This is the code that I used:

import signal
from beacontools.scanner import Monitor

def callback(bt_addr, rssi, packet, additional_info):
    print("<%s, %d> %s %s" % (bt_addr, rssi, packet, additional_info))

monitor = Monitor(callback,
                  bt_device_id = 0,
                  device_filter = None,
                  packet_filter = None,
                  scan_parameters = {})
monitor.start()
signal.pause()

bluetoothctl worked flawlessly with no adverse effects on WiFi and was able to correctly detect the Eddystone signal and data.

So I would conclude that the problem seems to be related to beacontools, not Bluez. Can I help to investigate the issue further?

@matzrh
Copy link
Author

matzrh commented Jul 11, 2021

@mrts : Sorry, I was busy and did not get around to follow your suggestion to try and install a higher bluez version, also because I was afraid that it could break some other bt related stuff I had set up with udev discovery rules.
Today I found the time, though, and interestingly/sadly enough, running the script with bluez 5.54 (which is the version available with debian buster-backports) and reverting scanner.py to the original version, I keep the same "Unknown HCI Command" errors in the btmon. It works again, fixing the the hci_version to '8'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants