Unable to maintain connection on a Raspberry Pi 4

[nathankellenicki]

Hi,

I have a Raspberry Pi 4b running Raspbian (Lite). While everything works fine on macOS and on a Raspberry Pi 3b, on a Raspberry Pi 4b, the connection is established, and works fine (both sending and receiving data) for about two seconds, before disconnecting.

  hci create le conn - writing: 010d20196000300000000c6f75f134a40006000c000000c80004000600 +4ms
  hci onSocketData: 040f0400010d20 +3ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 15 +0ms
  hci 		status = 0 +0ms
  hci 		cmd = 8205 +0ms
  hci onSocketData: 043e130100400000000c6f75f134a40c000000c80000 +38ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 62 +0ms
  hci 		LE meta event type = 1 +0ms
  hci 		LE meta event status = 0 +1ms
  hci 		LE meta event data = 400000000c6f75f134a40c000000c80000 +0ms
  hci 			handle = 64 +0ms
  hci 			role = 0 +1ms
  hci 			address type = public +0ms
  hci 			address = a4:34:f1:75:6f:0c +0ms
  hci 			interval = 15 +0ms
  hci 			latency = 0 +0ms
  hci 			supervision timeout = 2000 +1ms
  hci 			master clock accuracy = 0 +0ms
  att a4:34:f1:75:6f:0c: write: 020001 +5s
  hci write acl data pkt - writing: 024000070003000400020001 +1ms
  hci onSocketData: 011620024000 +1ms
  hci 	event type = 1 +0ms
  hci 		cmd = 8214 +0ms
  hci 		data len = 2 +1ms
  hci onSocketData: 040f0400011620 +0ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 15 +0ms
  hci 		status = 0 +1ms
  hci 		cmd = 8214 +0ms
  hci onSocketData: 010c20020000 +0ms
  hci 	event type = 1 +1ms
  hci 		cmd = 8204 +0ms
  hci 		data len = 2 +0ms
  hci 			LE enable scan command +0ms
  hci 			enable scanning = false +0ms
  hci 			filter duplicates = false +1ms
  noble scanStop +3s
  hci onSocketData: 040e0e0116200000000000000000000000 +0ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 14 +1ms
  hci 		cmd = 8214 +0ms
  hci 		status = 0 +0ms
  hci 		result = 00000000000000000000 +0ms
  hci onSocketData: 040e04010c2000 +1ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 14 +0ms
  hci 		cmd = 8204 +0ms
  hci 		status = 0 +0ms
  hci 		result =  +1ms
  hci onSocketData: 043e0c040040000100000000000000 +0ms
  hci 	event type = 4 +0ms
  hci 	sub event type = 62 +1ms
  hci 		LE meta event type = 4 +0ms
  hci 		LE meta event status = 0 +0ms
  hci 		LE meta event data = 40000100000000000000 +0ms
  hci onSocketData: 024020070003000400031700 +17ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 031700 +0ms
  att a4:34:f1:75:6f:0c: read: 031700 +27ms
  att a4:34:f1:75:6f:0c: new MTU is 23 +0ms
  att a4:34:f1:75:6f:0c: write: 100100ffff0028 +0ms
  hci write acl data pkt - writing: 0240000b0007000400100100ffff0028 +1ms
  hci onSocketData: 02402012000e0004001106010007000018080008000118 +29ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 1106010007000018080008000118 +0ms
  att a4:34:f1:75:6f:0c: read: 1106010007000018080008000118 +30ms
  att a4:34:f1:75:6f:0c: write: 100900ffff0028 +0ms
  hci write acl data pkt - writing: 0240000b0007000400100900ffff0028 +1ms
  hci onSocketData: 0240201a001600040011140900ffff23d1bcea5f782316deef121223160000 +29ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +1ms
  hci 		data = 11140900ffff23d1bcea5f782316deef121223160000 +0ms
  att a4:34:f1:75:6f:0c: read: 11140900ffff23d1bcea5f782316deef121223160000 +30ms
  bledevice Service/characteristic discovery started +5s
  att a4:34:f1:75:6f:0c: write: 080900ffff0328 +0ms
  hci write acl data pkt - writing: 0240000b0007000400080900ffff0328 +1ms
  hci onSocketData: 0240201b001700040009150a001c0b0023d1bcea5f782316deef121224160000 +28ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 09150a001c0b0023d1bcea5f782316deef121224160000 +1ms
  att a4:34:f1:75:6f:0c: read: 09150a001c0b0023d1bcea5f782316deef121224160000 +30ms
  att a4:34:f1:75:6f:0c: write: 080c00ffff0328 +0ms
  hci write acl data pkt - writing: 0240000b0007000400080c00ffff0328 +0ms
  hci onSocketData: 02402009000500040001080c000a +28ms
  hci 	event type = 2 +1ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 01080c000a +0ms
  att a4:34:f1:75:6f:0c: read: 01080c000a +29ms
  bledevice Service/characteristic discovery finished +59ms
  att a4:34:f1:75:6f:0c: write: 080a00ffff0229 +1ms
  hci write acl data pkt - writing: 0240000b0007000400080a00ffff0229 +1ms
  hci onSocketData: 0240200a000600040009040c000000 +29ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 09040c000000 +0ms
  att a4:34:f1:75:6f:0c: read: 09040c000000 +30ms
  att a4:34:f1:75:6f:0c: write: 120b000500010202 +0ms
  hci write acl data pkt - writing: 0240000c0008000400120b000500010202 +1ms
  hci onSocketData: 02402005000100040013 +28ms
  hci 	event type = 2 +1ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +0ms
  hci 		data = 13 +0ms
  att a4:34:f1:75:6f:0c: read: 13 +30ms
  att a4:34:f1:75:6f:0c: write: 120c000100 +0ms
  hci write acl data pkt - writing: 024000090005000400120c000100 +1ms
  hci onSocketData: 02402005000100040013 +29ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +1ms
  hci 		data = 13 +1ms
  att a4:34:f1:75:6f:0c: read: 13 +31ms
  att a4:34:f1:75:6f:0c: write: 120b000500010305 +1ms
  hci write acl data pkt - writing: 0240000c0008000400120b000500010305 +1ms
  hci onSocketData: 0240200d00090004001b0b00060001020600 +12ms
  hci 	event type = 2 +0ms
  hci 		cid = 4 +0ms
  hci 		handle = 64 +1ms
  hci 		data = 1b0b00060001020600 +1ms
  hci onSocketData: 04050400400008 +2s
  hci 	event type = 4 +1ms
  hci 	sub event type = 5 +1ms
  hci 		handle = 64 +0ms
  hci 		reason = 8 +1ms

Some cursory googling suggests event type = 5 is EVT_DISCONN_COMPLETE and reason = 8 is BLE_HCI_ERROR_CON_TIMEOUT.

Anyone know why this might be happening?

[derong97]

Hi, I am also using raspberry pi 4b, but the noble functions do not seem to be triggered. I have posted the question here too: noble#945

Did you manage to get that?

[nathankellenicki]

I don't have that problem, but I think it's a different issue. Have you run the setcap command here? https://github.com/abandonware/noble#linux

sudo setcap cap_net_raw+eip $(eval readlink -f $(which node))

[derong97]

Oh yes it works. Thank you so much!

[rzr]

I noticed that this line apear twice in README

Run the following command to grant node the necessary privileges to read BLE data: sudo setcap cap_net_raw+eip $(eval readlink -f $(which node)) (Explanation)

PR to merge both and make it clearer is welcome

[nathankellenicki]

@rzr Happy to do that, but some assistance with the original issue is also welcome.

[jovirus]

I have similar issue here, I managed to connect and receiving notification from my humidity sensor. However after I terminated the connection, it failed to reconnect(disconnect immediately after connection established).

When restart Pi, it works again.

[momsse]

Same here, work great on mac and disconnection issues on Raspbian (raspberry 3 and 4). Unfortunately it seems an old unresolved issue :/ (noble#485 and noble#465)

[atrovato]

@nathankellenicki did you find any solution?

[jncraton]

I had what I believe is the same issue as above, and I was able to resolve it by running the following commands to downgrade my Bluetooth firmware followed by a reboot.

wget http://archive.raspberrypi.org/debian/pool/main/b/bluez-firmware/bluez-firmware_1.2-4+rpt2_all.deb
sudo dpkg -i bluez-firmware_1.2-4+rpt2_all.deb

This appears to be an upstream Pi issue, and not a noble problem directly.

[airdrummingfool]

I believe I am running into a variant of this issue as well. On a Pi3b I can connect to a peripheral device, subscribe to a characteristic's notifications, and receive kilobytes of notifications with no problems. On a Pi4b with the same code, I receive ≈one notification and then immediately get disconnected (sometimes the disconnect happens before a notification, sometimes after a couple have been received).

The disconnect reason code is 8 (BLE_HCI_CONNECTION_TIMEOUT). When I look at the hci logs, it looks like the peripheral is exceeding the negotiated supervision timeout (1 second), which causes the timeout.

@jncraton's suggestion of downgrading bluez-firmware to 1.2-4+rpt2 fixes this on my Pi4b, and the peripheral no longer exceeds the supervision timeout (still 1 second with the older firmware). I found a relevant issue in the bluez-firmware repo: RPi-Distro/bluez-firmware#6, and it looks like they're working with Cypress to get the firmware fixed.

[JsBergbau]

I've encountered a similar problem on a RPi 4. With RPi Zero W it works.
On RPi 4 I need several connection attemps until connection is stable long enough and write handle requests suceeds.

However with gatttool there is no problem at all. So the question is why does noble fail and gatttool not?

I took a look with hcidump and on noble it shows

< ACL data: handle 64 flags 0x00 dlen 7
    ATT: MTU req (0x02)
      client rx mtu 256

This line is completly missing when connecting with gatttool where it works.
After that command issued hcidump shows

> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 64 packets 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x08
    Reason: Connection Timeout

I also manully changed with gatttool by "mtu 256" but it still worked.

Hopefully this is still helpful for you.