Process hangs on client disconnect

[wwaaijer]

Coming from v0.6, I was exited to upgrade Bleno to use the multiple connections support.
But I ran into an issue.

Reduced to a simple Bleno peripheral setup with a battery level service (read-only).
Client connects, reads the battery level, and disconnects after 3 seconds.
Everything works fine, until disconnecting.

When the client disconnects, the Node.js process just hangs and never emits the disconnect event.

Traced the issue with some logging throughout the disconnection process:

• Internally the disconnComplete event is emitted by the (main) hci-socket
• Bleno starts closing the internal aclStream belonging to the specific handle
• Which calls stop() on the hci socket (owned by the Mgmt class)
• This gets to BluetoothHciSocketWrapped.stop() in @stoprocent/bluetooth-hci-socket/lib/native.js
• From there, the Node.js process just hangs

Currently I lack the tools or expertise to debug the C++ code.
However, i would guess in BluetoothHciSocket.cpp that the pollingThread.join() is never returning for some reason?
Is the read call blocking, waiting for the socket to be closed, first?

Seems to have been working until just before v0.9.0, when the multiple connections support was added.
Running on a Raspberry Pi 3 B+ with Linux raspberrypi 6.1.21-v8, updated everything, Node.js v24.

P.S. already had great fun with your version of Bleno, thanks for your work on it!

[stoprocent]

Hey can you send me a sample script to replicate? And exact environment you are running it on? I do a lot of testing and never seen an issue.

[wwaaijer]

Sure! Thanks for the quick awnser.

Example code: https://github.com/wwaaijer/minimal-bleno-raspberry-pi-debug

Machine running the Bleno script:

Hardware: Raspberry Pi 3 B+
OS:       Linux raspberrypi 6.1.21-v8
Node.js:  v24.12.0

Packages installed:
libusb-1.0-0-dev  2:1.0.24-3
libudev-dev       247.3-7+deb11u7
bluetooth         5.55-3.1+rpt2+deb11u2
bluez             5.55-3.1+rpt2+deb11u2
libbluetooth-dev  5.55-3.1+rpt2+deb11u2

The client example I'm running in Windows w/ Chrome.
But also tested with geniric BLE apps like the "LightBlue" Android app by Punch Through for example

The server script hangs when this disconnect packet is received from the hci socket:

  hci onSocketData: 04050400400013 +6s
  hci   event type = 4 +1ms
  hci   sub event type = 5 +0ms
  hci           handle = 64 +0ms
  hci           reason = 19 +1ms

Full server script log and raspinfo: https://gist.github.com/wwaaijer/496380d5cdf2d31b75b85efc18cc37ce

Happy to provide any extra info I can.

[wwaaijer]

Playing around with this some more:

• I only see activity on the mgmt hci socket(s) when multiple devices have connected
  • Connecting/disconnecting the same device never triggers any mgmt socket activity
  • Never disconnecting the device, process hangs forever
• If there is activity on the mgmt socket(s)
  • Most of the time there is mgmt socket activity just before the disconnect, not after
  • In that case, connecting another device will trigger new mgmt socket activity and "officially" disconnect the device, at that moment
  • Sometimes when the mgmt socket activity does end up happining after the main hci socket receives the disconnComplete data, then the disconnect is working correctly!

It seems like a race condition between activity on the mgmt socket v.s. the main hci socket receiving the disconnComplete data, potentially blocking the C++ read call in the polling thread for the mgmt hci "control" socket?

The "only 1 device" case is even more weird, never receiving packets on that mgmt socket.

[wwaaijer]

I did not mean to close the issue, sorry 😅

[stoprocent]

Works fin on my end with multiple clients

[wwaaijer]

With multiple clients it kinda works, it's just that most of the time the disconnect event is only fired upon another device connecting/disconnecting.

Same for trying to exit the process, need a device to connect if we're in that weird state before to process closes.

Single device connecting/disconnecting consistently hangs the process for me on the Raspberry.

I would also assume the more limited proccessing power of the Raspberry Pi 3 might influence these timings?

[stoprocent]

I will test more tonight

[stoprocent]

Im using this almost daily at work so I would see the issue by now

[stoprocent]

closing due to #12 release

[wwaaijer]

Sorry, I should have clarified, #12 doesn't fix this issue, it fixed a seperate problem i noticed during debugging this.

I'm waiting for more hardware to arrive, to see if i can replicate the issue there or see how it is supposted to be working.
Also, i'm suspecting stoprocent/noble#30 is related to this, i'll do more testing.

[wwaaijer]

I've done more testing, with the Raspberry PI 3 and 5 BT radios, 2 BT dongles from different manufacturers and a laptop's BT radio. Both on Raspberry OS and Ubuntu. Consistently I see the same behavior as I described above.

Really trying hard to understand why you're not seeing the same behavior. My current hunch is in the direction of the very little activity I see on the HCI sockets.

Could it be that you're in an environment which causes continuous activity on both the HCI raw and control sockets?