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

[jlarsen]

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?

[Hung Bui]

You may need to modify the nrf_ble_gatt.c. Maybe extern a flag to the file and check if the flag is set before you call sd_ble_gattc_exchange_mtu_request(). Then you can set that flag inside main.c after you receive PM_EVT_BONDED_PEER_CONNECTED event.

Of you can remove the call sd_ble_gattc_exchange_mtu_request() inside nrf_ble_gatt.c and then call that function on your own in main.c

[jlarsen]

Thank you Hung Bui,  I was able to modify nrf_ble_gatt.c to not send an MTU request.  I believe Bluez (5.48) has a bug where it does not respond to MTU change requests after connecting to a bonded peer. It is true that the MTU should already be established and stored but the central should always respond to requests per the spec.