[jira] [Closed] (MYNEWT-326) ble_gattc_*_by_uuid callbacks called twice (with bogus data)

["Christopher Collins (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MYNEWT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Collins closed MYNEWT-326.
--------------------------------------
    Resolution: Not A Problem

Yes, you are correct - the second callback indicates that the discovery operation is complete.  You can determine that the procedure has successfully completed by checking the following:

* rc == 0
* service pointer is null

If your callback only gets executed once, and the parameters are as defined above, that means the peer device does not support the service you are interested in.

The reason for this somewhat awkward interface is that a device is allowed to support two different services with the same UUID.  To resolve this ambiguity, the callback gets executed with special values indicating discovery is complete.

That said, perhaps the interface could be improved.  I hadn't considered using a nonzero status code to indicate service complete, but BLE_HS_EDONE may make more sense than 0.

> ble_gattc_*_by_uuid callbacks called twice (with bogus data)
> ------------------------------------------------------------
>
>                 Key: MYNEWT-326
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-326
>             Project: Mynewt
>          Issue Type: Bug
>          Components: ble
>    Affects Versions: v0_9_0
>            Reporter: Simon Ratner
>
> Here's a log extract (mod=64 lines are mine, printed from relevant callbacks):
> {noformat}
> 1060:[ts=1035136ssb, mod=4 level=1] GAP procedure initiated: connect; addr_type=1 addr=47:b3:03:b7:5f:c6 scan_itvl=16 scan_window=16 itvl_min=24 itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=16 max_ce_len=768 our_addr_ty
> 2351:[ts=2295728ssb, mod=64 level=1] connection established; status=0 handle=1 peer_id_addr=47:b3:03:b7:5f:c6 peer_ota_addr=47:b3:03:b7:5f:c6 conn_itvl=40 conn_latency=0 supervision_timeout=256
> 2372:[ts=2316224ssb, mod=4 level=1] GATT procedure initiated: discover service by uuid; uuid=03040000-2aae-4d26-ad6203e9a8637ebd
> 2460:[ts=2402112ssb, mod=64 level=2] found svc; uuid=03040000-2aae-4d26-ad6203e9a8637ebd start_handle=40 end_handle=65535
> 2491:[ts=2432368ssb, mod=64 level=2] found svc; uuid=00000000-0000-3065-0000306500003015 start_handle=32768 end_handle=8192
> {noformat}
> Steps:
> 1. Connect
> 2. Call {{ble_gattc_disc_svc_by_uuid}} with a specific uuid
> 3. Observe callback invoked twice, the second time with {{end_handle < start_handle}} which is obviously invalid and subsequently fails with BLE_HS_EINVAL when passed to other gatt functions. 
> The {{error}} param is null in both invocations. Skimming the code, perhaps this has something to do with https://github.com/apache/incubator-mynewt-core/blob/develop/net/nimble/host/src/ble_gattc.c#L1346?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)