• State Verified Answer
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 3266 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 127320
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I am having a problem on the second connect after bonding to a bluez 5.43 central

jlarsen

I can connect/pair/bond to the nrfConnect app and disconnect then reconnect just fine. When I try to do the same to a central running on arm bluez 5.43, the second and subsequent connections timeout after about 30 seconds and the peripheral gets a BLE_GATTC_EVT_TIMEOUT and disconnects.

I have wireshark cptures of the nrf Connect connections and the failing connection to my central.

1st and 2nd connections working as expected rfconnect.pcapng

1st connection mycentral.pcapng

2nd connection (disconnected by peripheral after 30 seconds) mycentral2.pcapng

Parents
  • +1

    I do get a PM_EVT_BONDED_PEER_CONNECTED event before on_connected_evt() is called where sd_ble_gattc_exchange_mtu_request is called but I see no way of knowing in the nrf_ble_gatt.c on_connected_evt event that PM_EVT_BONDED_PEER_CONNECTED was called previous or any way to know that the connection is bonded. Is there any way of knowing this and conditionally calling the mtu request?

Reply
  • +1

    I do get a PM_EVT_BONDED_PEER_CONNECTED event before on_connected_evt() is called where sd_ble_gattc_exchange_mtu_request is called but I see no way of knowing in the nrf_ble_gatt.c on_connected_evt event that PM_EVT_BONDED_PEER_CONNECTED was called previous or any way to know that the connection is bonded. Is there any way of knowing this and conditionally calling the mtu request?

Children
No Data
Related