hcitool backend causes an ever increasing number of hcidump commands to run concurrently

[cj8scrambler]

When using the hcidump backend (either as root or with capabilities set on hcidump/hcitool) in a loop causes an ever increasing number of hcidump commands run concurrently.

Hardware: Raspberry Pi 3 Model B Plus Rev 1.3
adafruit-circuitpython-ble version: 9.0.1

To demonstrate, in one window run:

from adafruit_ble import BLERadio
import time

ble = BLERadio()
ble._adapter.ble_backend = "hcitool"

while True:
  for advertisement in ble.start_scan():
    print(f"Got BLE adv: {advertisement}")
  ble.stop_scan()

In another window, run:

 ps -ef | grep hcidump | wc -l

The number of hcidump commands running will keep increasing. The start_scan() call completes quickly (sometimes with data), causing another call. The new call starts hcidump again, but the previous hcidump command is still running.

The cause is that for some reason the poll() call in common.py is sometimes returning a 1 even though hcidump is still running fine. If I remove the returncode check in the while loop, then everything works as expected.

[cj8scrambler]

After digging some more, I realized that the poll() call is done on hcitool when it should be done on hcidump instead. On my system (Raspian Buster) with BlueZ 5.5, the hcitool lescan --duplicates command always fails with Set scan parameters failed: Input/output error. This seems to be common on BlueZ 5. It doesn't seem to matter that this fails. The hcidump command continues to run and is able to see duplicate BTLE advertisements. So the main loop in _start_scan_hcitool() should be polling on the status of the hcidump command.

I'll open a pull request to change this. All of this is probably tenuous and the package should move away from hcitools and towards a Bleak/D-Bus solution.

[dhalbert]

the package should move away from hcitools and towards a Bleak/D-Bus solution.

Yes, this is really what should happen. Our choice of hcidump vs. hcitools had to do with the proper duplication detection, and also what was working at the time (RPi was somewhat behind, I think).

bleak has moved forward many versions since I last worked on this library. There was a lot of churn going on and I could not safely advance the version across multiple platforms at once. Is there better scanning capability available through bleak on the three major platforms?

[tannewt]

IIRC it was the Linux kernel that deduplicated the advertisements. That's why I used hcidump. I haven't tracked if the kernel will actually gives us duplicates now. (This support is important to us because CP may be using advertisements to give varying data, not just initiating a connection like Linux assumes.)

[cj8scrambler]

This bleak issue makes it sounds like duplicate packet data may eventually be available, but for now hcidump seems to be the only solution.

The device I'm work with (Tilt hydrometer) also sends duplicate advertisements with some varying data.

[tannewt]

Nice find! Glad things are going the right direction.

[dhalbert]

@cj8scrambler I think you fixed this with #55. So closing. Correct me if I'm wrong.