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" <godbo...@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.blas...@qt.io> >Sent: November 1, 2018 11:11 AM >To: Jérôme Godbout <godbo...@amotus.ca>; nus1998 <nus1...@yeah.net> >Cc: interest@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...@qt-project.org> on >behalf of Jérôme Godbout <godbo...@amotus.ca> >Sent: Wednesday, 31 October 2018 3:16:01 PM >To: nus1998 >Cc: interest@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 <nus1...@yeah.net> >Sent: October 30, 2018 9:16 PM >To: Jérôme Godbout <godbo...@amotus.ca> >Cc: interest@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" ><godbo...@amotus.ca<mailto:godbo...@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...@qt-project.org<mailto:amotus...@qt-project.org>> > On Behalf Of nus1998 >Sent: October 30, 2018 4:42 AM >To: interest@qt-project.org<mailto:interest@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 > > > > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
