citruz / beacontools

A Python beacon scanning library.
MIT License
159 stars 58 forks source link

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

Open matzrh opened 3 years ago

matzrh commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 https://github.com/bowdentheo/BLE-Beacon-Scanner/issues/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 commented 3 years ago

@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'.