ble.recon module crashes on Raspberry Pi 3

[egglessness]

I'm trying to use the ble.recon command, but just after the first nearby devices show up, the module stops working: bettercap says that all the discovered devices were lost and I can't go on.

I use a Raspberry Pi 3 (environment details below), and I have zero problems enumerating, reading and writing characteristics on BLE devices using hcitool and gatttool.

Environment

• bettercap v2.24.1 (built for linux arm with go1.16.2)

• go version go1.16.2 linux/arm

• BlueZ (5.50-1.2~deb10u1+rpt2)

• Linux raspberrypi 5.10.17-v7+ armv7l GNU/Linux

• Command line arguments: none.

• Caplet code you are using or the interactive session commands: ble.recon on

• Full debug output while reproducing the issue ( bettercap -debug ... ):

bettercap v2.24.1 (built for linux arm with go1.16.2) [type 'help' for a list of commands]

[sys.log] [dbg] FindGateway(eth0) [cmd=ip opts=[route] parser=^(default|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\svia\s([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\sdev\s(\S+).*$]
[sys.log] [dbg] FindGateway(eth0) output:
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.121 metric 202
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.155 metric 303
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.155 metric 303
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.121 metric 202
[sys.log] [dbg] FindGateway(eth0) line 'default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.121 metric 202' matched with [default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.121 metric 202 default 192.168.2.1 eth0]
[sys.log] [dbg] gateway is 192.168.2.1[RE:DA:CT:ED:MA:CA]
[session.started] {session.started 2021-03-30 11:29:18.311260369 +0100 BST m=+0.236317721 <nil>}
[mod.started] events.stream

» ble.recon on
[sys.log] [dbg] ble.recon initializing device (id:-1) ...
[sys.log] [dbg] ble.recon [gatt.log] got 1 devices
[sys.log] [dbg] ble.recon [gatt.log] dev: hci0 up
[sys.log] [dbg] ble.recon [gatt.log] dev: hci0 reset
[sys.log] [dbg] ble.recon [gatt.log] dev: hci0 down
[sys.log] [dbg] ble.recon [gatt.log] dev: hci0 opened
[sys.log] [dbg] ble.recon [gatt.log] hci.mainLoop started
[sys.log] [dbg] ble.recon starting discovery ...
[sys.log] [dbg] ble.recon state changed to PoweredOn
[mod.started] ble.recon
[sys.log] [dbg] ble.recon started devices pruner ...
[ble.device.new] new BLE device detected as RE:DA:CT:ED:MA:CA (Apple, Inc.) -90 dBm.
[ble.device.new] new BLE device detected as RE:DA:CT:ED:MA:CA (Apple, Inc.) -90 dBm.
[ble.device.new] new BLE device detected as RE:DA:CT:ED:MA:CA (Apple, Inc.) -88 dBm.
[ble.device.new] new BLE device detected as RE:DA:CT:ED:MA:CA (Apple, Inc.) -45 dBm.
[ble.device.new] new BLE device GB5_GB000000 detected as RE:DA:CT:ED:MA:CA -57 dBm.
[ble.device.new] new BLE device detected as RE:DA:CT:ED:MA:CA (Apple, Inc.) -91 dBm.
[sys.log] [dbg] ble.recon [gatt.log] mainloop err: interrupted system call

» ble.enum RE:DA:CT:ED:MA:CA

* HERE IT HANGS *

[ble.device.lost] BLE device RE:DA:CT:ED:MA:CA (Apple, Inc.) lost.
[ble.device.lost] BLE device RE:DA:CT:ED:MA:CA (Apple, Inc.) lost.
[ble.device.lost] BLE device RE:DA:CT:ED:MA:CA (Apple, Inc.) lost.
[ble.device.lost] BLE device RE:DA:CT:ED:MA:CA (Apple, Inc.) lost.
[ble.device.lost] BLE device GB5_GB000000 RE:DA:CT:ED:MA:CA lost.
[ble.device.lost] BLE device RE:DA:CT:ED:MA:CA (Apple, Inc.) lost.

Steps to Reproduce

1. ble.recon on
2. ble.enum MACADDRESS

Expected behavior:
Successfully enumerating characteristics on a found BLE device

Actual behavior:
All found devices are lost and I can't go on

As far as I noticed, it seems that everything stops working as soon as this error shows up:

[sys.log] [dbg] ble.recon [gatt.log] mainloop err: interrupted system call

How can I get gatt.log to figure out what's happening?

[egglessness]

Looking at the README in the gatt repo, I also tried to set hci0 down and stop the built-in bluetooth service:

sudo hciconfig hci0 down
sudo service bluetooth stop

But it still doesn't work :(

[electronjoe]

I'm unclear on the relationship between bettercap/bettercap and bettercap/gatt, but I'm running a Rpi 3B and observing the same error message (mainloop err: interrupted system call) but from bettercap/gatt.

What's interesting is that a previous build of my binary (~month ago) did not exhibit this behavior. For that binary, my go.mod was pinned to the following version of gatt.

Healthy binary on RPI 3B+

github.com/bettercap/gatt v0.0.0-20191018133023-569d3d9372bb

Environment of failure

• gatt checked out at 7a3c1c59fe925b31e13fc83c28ba2e7ebb789ab4

ubuntu@rpi:/tmp/gatt$ go version
go version go1.14.7 linux/arm

ubuntu@rpi:/tmp/gatt$ dpkg --status bluez | grep '^Version:'
Version: 5.55-0ubuntu1

ubuntu@rpi:/tmp/gatt$ uname -a
Linux rpi 5.8.0-1019-raspi #22-Ubuntu SMP PREEMPT Sat Mar 20 01:08:56 UTC 2021 armv7l armv7l armv7l GNU/Linux

[electronjoe]

Wondering whether there is need for some EINTR retry handling somewhere in these libraries or a dependency?

Edit: Wonderig if Golang 1.14 could be at play / interacting with bettercap/gatt with unexpected EINTR though the OP was using 1.16...

[electronjoe]

FWIW I tried both a full reboot of the rpi, and:

sudo hciconfig hci0 down
sudo service bluetooth stop
sudo service bluetooth start
sudo hciconfig hci0 up

And continued to receive mainloop err: interrupted system call within maybe a handful of receptions.

Downgrading Go fixed my issue.

ubuntu@rpi:~/gatt$ go version
go version go1.13.8 linux/arm

[evilsocket]

does this happen on the latest stable version of bettercap?