Gatt Browser - Cannot Discover Services from specific device

[David Lee]

Hello,

I am using btstack on an FreeRTOS platform, communicating with a TI WL183x device over H4 UART. I have been testing with the gatt_browser example and I have successfully used this example with a few devices and been able to view their services and characteristics.

However, for my final system, I want to use a JBL Click (a simple HID) and I have so far not had success browsing services from this device. After calling `gap_connect` and receiving the `HCI_SUBEVENT_LE_CONNECTION_COMPLETE` event, the device then disconnects, before we can query the services.

Can you tell whats going wrong with this connection? The biggest mystery is why browsing this JBL Click device fails, while other devices seem to work fine. HCI packet log available here: https://nextcloud.ara.com/nextcloud/index.php/s/D8nFGojSRqQYNsg

[Matthias Ringwald]

HI David

The log is a bit strange, e.g. the time jumps back 

Jan 01 17:00:20.150  Note             0x0000  0:00:19.440] EVT <= 6E 00   

Jan 01 17:00:19.440  HCI Event        0x0000  Command Complete [1002] - Read Local Supported Commands  

Jan 01 17:00:19.460  Note             0x0000  hci.c.2488: Command 0x00 supported 2/5  

..

packets are repeated here

…

Jan 01 00:00:01.000  Note             0x0000  sm.c.2175: LE Device Lookup: device 0/16  

… time jumps back to zero

and there also packets missing, e.g. there are comments about creating the connection, but the HCI LE Create Connection packet is missing.

Could you try to make sure the log contains all packets in the correct order?

—

As for your original problem, I can only see the ATT MTU Request and then a disconnect 10 ms later - which is very quick as if it would be annoyed by the request. You may try to reduce the MTU e.g. by reducing HCI_ACL_PAYLOAD_SIZE to 200 in the btstack_config.h

—

Can you browse the GATT Services from a smartphone, e.g. using LightBlue? (HID services are handled by the OS on iOS)

Best

 Matthias

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/e10c62cf-6143-46fe-bb01-f7ff173ff709n%40googlegroups.com.

[David Lee]

Thanks for your reply Matthias. I have addressed the issue with our debug logging, all messages should be in the order expected. Please find the latest HCI packet log here: https://nextcloud.ara.com/nextcloud/index.php/s/6HywPb4BeqEJqJs

In the above log, I have updated our HCI_ACL_PAYLOAD_SIZE to 258 (the minimum size required by an assert in the cc256x chipset code). I do not see any difference in behavior of the gatt browser application.

Yes, I can browse services for this device using an Android app. According to that, this device should have 6 services available.

Thank you!

[Matthias Ringwald]

Hi David

Thanks for the updated log / it's clean now.

So, to recap: you connect to the JBL Click, start a GATT Service Query which triggers an MTU exchange and you get a disconnect. 

Can you get an HCI log from a device where the GATT browsing works? We can then try to match that. E.g. on Mac OS, you can install PacketLogger from the Xcode Hardware Tools. On Android, it’s possible to get a BTsnoop file on some devices but this differs by vendor/OS version.

Nothing in the log is wrong, but you can:

a) play with the connection parameters

b) request BTstack to encrypt the connection before exchanging any data with gatt_client_set_required_security_level(LEVEL_2)

c) reduce MTU even lower (iOS uses 158 or 185 usually - with l2cap_set_max_le_mtu(150)

d) disable MTU exchange with gatt_client_mtu_enable_auto_negotiation(0)

Best

 Matthias

To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/508af85b-c799-4bf0-87e5-b296045f04c5n%40googlegroups.com.

[David Lee]

Matthias,

Thanks for your advice. I actually found that after looking at the performance on Android, if i re-initiated a connection attempt soon after the disconnect (within about 1.5 seconds), the JBL Click device subsequently stays connected and is able to pair.

Is this something you have seen in other devices? Requiring multiple connection attempts?

In any event, I am able to make progress with this device. Thanks!

[Matthias Ringwald]

Hi David

That's quite interesting. No, I haven't seen such a 'protocol" before. I don't see why this should be on purpose, it might just be a bug and the automatic retry on Android gets around it.
I'll keep it in mind for the case where anything else fails :)

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/b300847c-efeb-4446-b060-75f8e4fc5a9bn%40googlegroups.com.