Thread (2 messages) flat view 2 messages, 2 authors, 2021-07-26

Re: Instable BLE connection - MTU Request, Attribute not found

From: Emil Lenngren <hidden>
Date: 2021-07-26 15:34:29

Hi Peter,

Den mån 26 juli 2021 kl 12:58 skrev Peter Höller [off-list ref]:
Hello!

My name is peter. This is probably a bit off topic but:
Since about 2 years I am working ambitiously on connecting a GoPro to
an Odroid via HTTP, UDP and BLE in order to get a powerful node-red
controlled dashcam/balckbox for my cars (fleet control).
(please see: https://github.com/cepoon/GoProRemote,
https://github.com/KonradIT/goprowifihack,
https://github.com/sepp89117/GoPro-Multiple-Smart-Remote-ESP8266)

However I stumbled over a thread: #96, which's owner forwarded me to
your mailing list as my last resort:

and figured that you are deep into debugging of BLE connections.

because of our long developement period we are "stuck" in a somewhat
older hardware/kernel  config, unfortunately:

Odroid C2 with BluetoothModule2 (CSR8510 A10)
Ubuntu 18.04 (Kernel 3.16.85+)
WifiModule 5A (concurrent mode (STA+Client) on hostapd 2.9)
Bluez 5.53
btusb 0.7
(- GoPro Hero5 black)

However, we do suffer from an comparable annoying problem since more
than a year(!). We do have an unstable BLE Connection between Dongle
and Gopro. When just paired, the first connection stays up for about
30mins (abortion the is not btmon-itored yet, but can be done), but
the reconnect is a problem: gets connected but after 2 - 15 sec:
disconnect. Mainly because of:

#Issue 1: (btmon) Why is it disconnecting after MTU request?
@ Discovering: 0x00 (6)

HCI Event: Command Status (0x0f) plen 4 #111 [hci0] 55.051270
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 19 #112 [hci0] 55.626431
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 71
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: C9:0F:D9:47:48:B4 (Static)
Connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ Device Connected: C9:0F:D9:47:48:B4 (2) flags 0x0000
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #113 [hci0] 55.627789
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
HCI Event: Disconnect Complete (0x05) plen 4 #114 [hci0] 56.035562
Status: Success (0x00)
Handle: 71
Reason: Connection Failed to be Established (0x3e)
@ Device Disconnected: C9:0F:D9:47:48:B4 (2) reason 0

#issue 2: btmon: Error: Timeout/ Disconnect after attribute not
found!? (main issue obviously)
@ Discovering: 0x00 (6)
<< HCI Command: LE Create Connect.. (0x08|0x000d) plen 25 #102 [hci0] 21.277573
Scan interval: 60.000 msec (0x0060)
Scan window: 30.000 msec (0x0030)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: C9:0F:D9:47:48:B4 (Static)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)

HCI Event: Command Status (0x0f) plen 4 #103 [hci0] 21.281234
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 19 #104 [hci0] 21.474300
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 71
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: C9:0F:D9:47:48:B4 (Static)
Connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ Device Connected: C9:0F:D9:47:48:B4 (2) flags 0x0000
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #105 [hci0] 21.475604
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
HCI Event: Number of Completed Packets (0x13) plen 5 #106 [hci0] 21.786387
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 7 #107 [hci0] 21.849441
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #108 [hci0] 21.849849
ATT: Read Request (0x0a) len 2
Handle: 0x0004
HCI Event: Number of Completed Packets (0x13) plen 5 #109 [hci0] 21.919448
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 15 #110 [hci0] 21.989485
ATT: Read Response (0x0b) len 10
Value: 476f50726f2038353339
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #111 [hci0] 21.989865
ATT: Read Request (0x0a) len 2
Handle: 0x0006
HCI Event: Number of Completed Packets (0x13) plen 5 #112 [hci0] 22.059476
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 7 #113 [hci0] 22.135894
ATT: Read Response (0x0b) len 2
Value: 8000
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #114 [hci0] 22.136253
ATT: Read Request (0x0a) len 2
Handle: 0x000e
HCI Event: Number of Completed Packets (0x13) plen 5 #115 [hci0] 22.199508
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 6 #116 [hci0] 22.269695
ATT: Read Response (0x0b) len 1
Value: 05
<< ACL Data TX: Handle 71 flags 0x00 dlen 7 #117 [hci0] 22.270106
ATT: Read Request (0x0a) len 2
Handle: 0x0020
HCI Event: Number of Completed Packets (0x13) plen 5 #118 [hci0] 22.339554
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 12 #119 [hci0] 22.409721
ATT: Read Response (0x0b) len 7
Value: 00000000000000
<< ACL Data TX: Handle 71 flags 0x00 dlen 11 #120 [hci0] 22.410113
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
HCI Event: Number of Completed Packets (0x13) plen 5 #121 [hci0] 22.479592
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 27 #122 [hci0] 22.549760
ACL Data RX: Handle 71 flags 0x01 dlen 9 #123 [hci0] 22.551041
ATT: Read By Group Type Response (0x11) len 31
Attribute data length: 6
Attribute group list: 5 entries
Handle range: 0x0001-0x0001
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x0002-0x0008
UUID: Generic Access Profile (0x1800)
Handle range: 0x0009-0x000b
UUID: Tx Power (0x1804)
Handle range: 0x000c-0x000f
UUID: Battery Service (0x180f)
Handle range: 0x0010-0x0020
UUID: Device Information (0x180a)
<< ACL Data TX: Handle 71 flags 0x00 dlen 9 #124 [hci0] 22.551281
ATT: Write Request (0x12) len 4
Handle: 0x000f
Data: 0100
HCI Event: Number of Completed Packets (0x13) plen 5 #125 [hci0] 22.695655
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 5 #126 [hci0] 22.759830
ATT: Write Response (0x13) len 0
<< ACL Data TX: Handle 71 flags 0x00 dlen 11 #127 [hci0] 22.760241
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0021-0xffff
Attribute group type: Primary Service (0x2800)
HCI Event: Number of Completed Packets (0x13) plen 5 #128 [hci0] 22.829698
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 26 #129 [hci0] 22.899859
ATT: Read By Group Type Response (0x11) len 21
Attribute data length: 20
Attribute group list: 1 entry
Handle range: 0x0021-0x002c
UUID: Vendor specific (b5f90001-aa8d-11e3-9046-0002a5d5c51b)
<< ACL Data TX: Handle 71 flags 0x00 dlen 11 #130 [hci0] 22.900311
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x002d-0xffff
Attribute group type: Primary Service (0x2800)
HCI Event: Number of Completed Packets (0x13) plen 5 #131 [hci0] 23.039754
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 12 #132 [hci0] 23.109915
ATT: Read By Group Type Response (0x11) len 7
Attribute data length: 6
Attribute group list: 1 entry
Handle range: 0x002d-0x0041
UUID: GoPro, Inc. (0xfea6)
<< ACL Data TX: Handle 71 flags 0x00 dlen 11 #133 [hci0] 23.110286
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0042-0xffff
Attribute group type: Primary Service (0x2800)
HCI Event: Number of Completed Packets (0x13) plen 5 #134 [hci0] 23.185785
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 26 #135 [hci0] 23.319981
ATT: Read By Group Type Response (0x11) len 21
Attribute data length: 20
Attribute group list: 1 entry
Handle range: 0x0042-0x0047
UUID: Vendor specific (b5f90090-aa8d-11e3-9046-0002a5d5c51b)
<< ACL Data TX: Handle 71 flags 0x00 dlen 11 #136 [hci0] 23.320349
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0048-0xffff
Attribute group type: Primary Service (0x2800)
HCI Event: Number of Completed Packets (0x13) plen 5 #137 [hci0] 23.389838
Num handles: 1
Handle: 71
Count: 1
ACL Data RX: Handle 71 flags 0x02 dlen 9 #138 [hci0] 23.458793
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0048
Error: Attribute Not Found (0x0a)
HCI Event: Disconnect Complete (0x05) plen 4 #139 [hci0] 24.160066
Status: Success (0x00)
Handle: 71
Reason: Connection Timeout (0x08)
@ Device Disconnected: C9:0F:D9:47:48:B4 (2) reason 1

for sure there are Authentification failures too, but I cannot
btmon-capture 'em right now.

However, it is really hard to find somebody who has a glue what is
going on here, and where the best, we should start to debug.

So please can you help us any further.

We are struggeling for a solution on this for years.

greets

peter
To understand the "Connection failed to be established" disconnect
reason, let me first explain the connection process in BLE:
1. Peripheral emits ADV_IND advertising packets repeatedly with some
interval, containing its Bluetooth device address and some optional
advertising data.
2. A central device which is currently in the initiating state scans
for these advertising packets and when one is found with the correct
target address, it will reply after exactly 150 microseconds with a
CONNECT_IND packet.
3. The central is now in the "connected" state and this fact is sent
to the host using a "LE Connection Complete Event".
4. At the peripheral side, the "connected" state is entered when it
receives the CONNECT_IND packet.

In the connected state, the central emits one packet (possibly empty)
once per connection interval and the peripheral must respond within
150 microseconds. If there is no response for the first six packets in
a connection, the central will treat the connection disconnected with
the reason "Connection failed to be established". If the peripheral
responds at least once, but after that at any time it doesn't respond
to a central's packet within the set supervision timeout, the
"Connection Timeout" disconnect reason will happen.

We can derive a few reasons why "Connection failed to be established" occurs:

1. If the CONNECT_IND packet is lost in the air, the peripheral does
not enter the connected state, but the central does. In this case the
peripheral will not respond to any other packet the central sends,
since the peripheral is not in the connected state.
2. The peripheral could use white listing to allow connections from
only specific centrals. In this case the central will always see a
connection complete immediately followed by a connection failed to be
established.
3. Bad signal quality could mean the peripheral detects the
CONNECT_IND but not any of the first six packets sent by the central.
4. A bad link layer scheduler in any of the two bluetooth controllers
could skip the first six connection events.

With the new extended advertising packet format introduced in
Bluetooth 5.0 that not many devices use, an extra acknowledgement is
sent from the peripheral after it receives the CONNECT_IND to mitigate
this confusion a bit.

Common reasons for the Connection Timeout are bad signal quality or a
bad link layer scheduler, or possibly too much overlapping work
scheduled for the radio.

Anyway, nothing is wrong at the host side (BlueZ) for these problems.
It just happened that the MTU Request and Attribute Not Found packets
were the last ones before the disconnection occurred. You should use
an air sniffer for BLE to maybe get some more insight.

/Emil
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help