Unable to maintain connection on a Raspberry Pi 4
nathankellenicki opened this issue · 11 comments
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?
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?
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))
Oh yes it works. Thank you so much!
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
PR to merge both and make it clearer is welcome
@rzr Happy to do that, but some assistance with the original issue is also welcome.
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.
@nathankellenicki did you find any solution?
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.
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.
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.