[Interest] QLowEnergyController always disconnected after service discovery finished

Tue Nov 13 02:26:42 CET 2018

Hi,

Thanks for your comments, in the past several days I got some information that the peripheral needs to be bonded before communication, so I'm confused that does QLowEnergyController or any agent support it?

The host needs to send a request with a passkey for bonding, and confirm with a auth token on bonding response.

B.R.
Jie

在 2018-11-02 02:22:38，"Jérôme Godbout" <godboutj at amotus.ca> 写道：
>A good reference for the BLE snoops is here:
>http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm
>
>Note: take care, Samsung device (yet again) have a different path form all other devices.
>
>-----Original Message-----
>From: Alex Blasche <alexander.blasche at qt.io> 
>Sent: November 1, 2018 11:11 AM
>To: Jérôme Godbout <godboutj at amotus.ca>; nus1998 <nus1998 at yeah.net>
>Cc: interest at qt-project.org
>Subject: Re: [Interest] QLowEnergyController always disconnected after service discovery finished
>
>Hi,
>
>all the comments from Jérôme apply and unfortunately I have had similar issues with early Android devices/versions.
>
>I wanted to add one more way you can debug on Linux (since that's what you are using). You may use wireshark which can log the traffic on your local bt device. Maybe this reveals sth...
>
>In this case the error message says that the cause is somewhere on the peripheral side. Therefore you may even want to enable some sort of logging on the peripheral side. If it happens to be an Android device you can for example enable HCI logging in the developer options.
>
>--
>Alex
>
>________________________________________
>From: Interest <interest-bounces+alexander.blasche=qt.io at qt-project.org> on behalf of Jérôme Godbout <godboutj at amotus.ca>
>Sent: Wednesday, 31 October 2018 3:16:01 PM
>To: nus1998
>Cc: interest at qt-project.org
>Subject: Re: [Interest] QLowEnergyController always disconnected after service discovery finished
>
>Hi,
>I'm still having some trouble with some particular Android device running 5.0.1 to 5.1.1 that I could not figure out so far. I have trouble attaching adb to those devices (thanks Samsung for the missing commands). But I have seen some MTU badly handled on devices making the disconnection.
>
>If you connect successfully and do nothing else and the connection reset, it might be a message that is badly handled by the device and the BLE stack on old Android seem picky about thoses error.  The 15 seconds if constant after connection probably point to some exchange at lower level.
>
>You might want to test with NRFConnect and monitor the whole exchange with the console into that application. This might give you some hint for the device side fixes (if you can control that part).  The unknown problems mention above I can repeat them with NRFConnect but I'm still not sure why the BlueZ want to disconnect even if MTU is handled properly by device (as per specification at least).
>
>If you have any information we could share the information and maybe I could finally find a fix (or a workaround) for this. Here's my list of device that display the problem for me and the information I have gather so far:
>
>
>  *   Open nRFConnect application
>  *   Connect to the device
>  *   Into the top right options (3 dots icon) select show log
>  *   Use the debug level from the lower left corner
>  *   Once the device connect and the device finish discovering application services and characteristic, it will display the following error:  Error 34 (0x22) GATT CONN LMP TIMEOUT
>Device that show th problems:
>
>  *   Google Nexus 7", Android 6.0.1 (the only one I could test out).
>  *   Galaxy S4, Android 5.0.1  (debug impossible from Qt Creator)
>  *   Galaxy Tab A, Android 5.1.1 (debug impossible from Qt Creator)
>  *   LG K4 LTE, Android 5.1.1 (I don't have this device, it's a client that had it)
>Deives that doesn't show this behavior that I have tested and debugged:
>
>  *   Google LG Nexus 5, Android 6.0.1
>  *   All iOS device
>  *   LG (multiples one with Android 8.0)
>  *   Google Pixel 2 Android 9.0
>
>Good luck,
>Jerome
>
>From: nus1998 <nus1998 at yeah.net>
>Sent: October 30, 2018 9:16 PM
>To: Jérôme Godbout <godboutj at amotus.ca>
>Cc: interest at qt-project.org
>Subject: Re:RE: [Interest] QLowEnergyController always disconnected after service discovery finished
>
>Hi Jerome,
>
>Thanks for your advice, I seperated charateristics reading with service discovery and Error1:"no attribute in ..." is disappeared.
>
>However, the QLowEnergyController is still disconnected several seconds after service discovery is finished, still there is error of "Connection timed out" or "Connection reset by peer". I wonder is this BLE feature and is it normal? as when I use "BLE analyser" on android phone to read BLE devices, there are all automatically disconnected in several seconds after connection is estabilished.
>
>B.R.
>Jie
>
>
>At 2018-10-30 21:10:34, "Jérôme Godbout" <godboutj at amotus.ca<mailto:godboutj at amotus.ca>> wrote:
>
>Hi,
>
>You should find and resolve the first error, any error could lead to disconnection:
>qt.bluetooth.bluez: Error1: "no attribute in given range found" last command: 10 handle: 1 m_controller discoveryFinished Also make sure you finish the discovery before you start doing any other services/characteristics discovery with BlueZ.
>
>Side note: In the case of the Bluez (especially the Android one), give it some delay between your request and avoid sending multiple request at the same time. After you connect put a sleep delay of a few hundred ms and always request a single services and characteristic at a time.
>
>The stack is so buggy it's the only way to make it work properly and reliably. Don't base your "it work" with BlueZ on a single test run, the results change a lot with the device load and BLE usage by other application. iOS and OS X on the other hand seem t work just fine, they do not need the artificial delay, so it's a delay festival with ifdef.
>
>Jerome
>
>From: Interest <interest-bounces+godboutj=amotus.ca at qt-project.org<mailto:amotus.ca at qt-project.org>> On Behalf Of nus1998
>Sent: October 30, 2018 4:42 AM
>To: interest at qt-project.org<mailto:interest at qt-project.org>
>Subject: [Interest] QLowEnergyController always disconnected after service discovery finished
>
>Hi,
>When I use QLowEnergyController to scan the service, it's always disconnected about 15 seconds after services discovery is finished. the error is not certain, sometimes it's "Connection reset by peer", sometimes it's "Connection timeout".
>
>The log is attached, can anyone have a look at it and give me some advice? thanks in advance.
>
>qt.bluetooth.bluez: Bluez 5 detected.
>qt.bluetooth.bluez: Creating QtBluezDiscoveryManager m_discoveryAgent is active
>qt.bluetooth.bluez: BluetoothManagement: Ignored event: 13
>qt.bluetooth.bluez: Discovered:  "00:07:80:2E:9B:85" "BLE Module" Num UUIDs 0 total device 0 cached RSSI -94 Class 0 "00:07:80:2E:9B:85" "00:07:80:2E:9B:85" "BLE Module" QFlags(0x1)
>qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()
>found lead MkIII
>qt.bluetooth.bluez: Enabling GATT request timeout behavior 20000
>qt.bluetooth.bluez: addresstypeToUse: "Public"
>qt.bluetooth.bluez: No settings found for peer device.
>qt.bluetooth.bluez: BluetoothManagement: Ignored event: 13
>qt.bluetooth.bluez: HCI event triggered, type: f
>qt.bluetooth.bluez: HCI event triggered, type: 3e
>qt.bluetooth.bluez: received connection complete event, handle: 1025
>qt.bluetooth.bluez: BluetoothManagement: Ignored event: b
>qt.bluetooth.bluez: Current l2cp sec level: 1
>qt.bluetooth.bluez: Exchanging MTU
>m_controller connected
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 1 endHandle: ffff 2800
>qt.bluetooth.bluez: Received size: 3 data: "031700"
>qt.bluetooth.bluez: Server MTU: 23 resulting mtu: 23
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: Received size: 8 data: "1106010005000018"
>qt.bluetooth.bluez: Found uuid: "{00001800-0000-1000-8000-00805f9b34fb}" start handle: 1 end handle: 5 service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 6 endHandle: ffff 2800
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: Received size: 22 data: "111406001200e34bc643730f1e930e7fe83ae1b11fab"
>qt.bluetooth.bluez: Found uuid: "{ab1fb1e1-3ae8-7f0e-931e-0f7343c64be3}" start handle: 6 end handle: 12 service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 13 endHandle: ffff 2800
>qt.bluetooth.bluez: Received size: 14 data: "1106130017000a1818001a000518"
>qt.bluetooth.bluez: Found uuid: "{0000180a-0000-1000-8000-00805f9b34fb}" start handle: 13 end handle: 17 service discovered
>qt.bluetooth.bluez: Found uuid: "{00001805-0000-1000-8000-00805f9b34fb}" start handle: 18 end handle: 1a service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 1b endHandle: ffff 2800
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: Received size: 22 data: "11141b002d00e8b84b71b98489ab01fb06bec3bad7af"
>qt.bluetooth.bluez: Found uuid: "{afd7bac3-be06-fb01-ab89-84b9714bb8e8}" start handle: 1b end handle: 2d service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 2e endHandle: ffff 2800
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: Received size: 22 data: "11142e0044000adea862315e215dbab961a5b3dc493c"
>qt.bluetooth.bluez: Found uuid: "{3c49dcb3-a561-b9ba-5d21-5e3162a8de0a}" start handle: 2e end handle: 44 service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 45 endHandle: ffff 2800
>qt.bluetooth.bluez: Received size: 22 data: "11144500fffffac79ce402ae50e53c3c6b32ffba88f7"
>qt.bluetooth.bluez: Found uuid: "{f788baff-326b-3c3c-e550-ae02e49cc7fa}" start handle: 45 end handle: ffff service discovered
>qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 1 endHandle: ffff 2801
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: Received size: 5 data: "011001000a"
>qt.bluetooth.bluez: Error1: "no attribute in given range found" last command: 10 handle: 1 m_controller discoveryFinished
>qt.bluetooth.bluez: HCI event triggered, type: 13
>qt.bluetooth.bluez: HCI event triggered, type: 5
>qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 19 error: -1 "Connection reset by peer"
>m_controller disconnected
>qt.bluetooth.bluez: BluetoothManagement: Ignored event: c B.R.
>Jie
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181113/1ae01700/attachment.html>