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

[Hung Bui]

Hi Larsen,

It's not clear in mycentral2.pcapng what exactly cause the disconnection. The connection timeout was set to 52.5 seconds, but the connection was terminated much earlier than that.

A BLE_GATTC_EVT_TIMEOUT meaning there was a write request sent but never get a response. Do you do any write request from the nRF5 side ?

Since the sniffer file the encrypted packets was not decrypted correctly I can't tell what could be wrong here. I suspect the LTK keys was not stored correctly.

You may want try sniffing again and try to sniff with one take that cover both the first connection (when they bond) and the second connection, all in one sniffer trace.

If you test with something like the ble_app_proximity and test bonding and reconnect, do you have the same problem ?

Which chip and softdevice were you using ? nRF51 and S132 don't go together.

[jlarsen]

softdevice = s132 chip = nRF52

ble_app_proximity does the same thing in that it disconnects after 30 seconds. The connection parameters seem to work better in the proximity app. I actually see them set on the central side.

I have been using the nRF52 board to sniff. Theres are some issues doing this. I will post the sniffer results once I get a board that that the sniffer code works on.

I am not sure if we do write requests but we do attempt to change the MTU

[Hung Bui]

Our current sniffer doesn't really support BLE 4.2 features, so it may be difficult to sniff the connection. I would suggest to use more advanced sniffer, Ellysis or Frontline sniffer should do the work.

[jlarsen]

It will take some time for us to be able to sniff the ble traffic to a level that will help. In the meantime I think I have found what is going on and have some further questions. On every connection, if our MTU is not default 23, we send an MTU exchange request. On the first connection the bluez based central sends a MTU exchange response and everyhing is fine. On the second connection we never receive an MTU echange response and 30 seconds later we timeout and disconnect. I do think that bluez is in error here although they wonder why the peripheral is sending an MTU request when we are already bonded/paired. My question is, is there a way to have the software on the peripheral only send an MTU exchange request on the first connection to a central and not again on the subsequent connections to a bonded/paired central?

[Hung Bui]

Hi Larsen,

MTU request is sent by the peripheral by the call sd_ble_gattc_exchange_mtu_request() to the softdevice.

Most of the time this is called inside on_connected_evt() in nrf_ble_gatt.c

You can modify the code so that it won't call if the link is encrypted. (You will receive PM_EVT_BONDED_PEER_CONNECTED event from peer manager if it's a previously bonded peer )