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

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

jlarsen — Wed, 28 Feb 2018 16:53:31 GMT

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.

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

Hung Bui — Tue, 28 Nov 2017 14:30:18 GMT

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

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

jlarsen — Mon, 27 Nov 2017 23:06:23 GMT

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?

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

Hung Bui — Thu, 23 Nov 2017 12:51:13 GMT

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 )

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

jlarsen — Wed, 22 Nov 2017 18:48:22 GMT

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?

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

Hung Bui — Mon, 20 Nov 2017 14:11:15 GMT

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.

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

jlarsen — Fri, 17 Nov 2017 20:30:33 GMT

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

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

Hung Bui — Fri, 17 Nov 2017 16:07:58 GMT

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.