Error with some phones when change the NRF_SDH_BLE_GATT_MAX_MTU_SIZE greater that 23.

[DimitrisP]

If I change the NRF_SDH_BLE_GATT_MAX_MTU_SIZE  in sdk_config.h to any value greater than 23, immediately after connecting the stack executes a sd_ble_gattc_exchange_mtu_request function. That results in an error like the photo (not in all the phones). Is it normal and I have to leave the android app to change MTU, or is something wrong?

SDK 17

nRF52 DK as a peripheral

Action: Trying to bound with the peripheral from phones BLE page

[awneil]

Have you looked-up what disconnect reason 0x13 means ?

It'll be a BT-SIG standard code...

[Edvin]

Hello,

Disconnect reason 0x13 means BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION, so it looks like the other device disconnected. What phone models is it that disconnect? Typically old models?

Does it only happen if you increase the MTU, or is it because of the bonding? Please ensure that you don't have old bonding data in only one of the devices (that means, try to delete it on both devices). On the nRF, run "nrfjprog --eraseall" and go to the bluetooth settings on the phone and select something like "forget device".

BR,
Edvin

[DimitrisP]

Of cource but that is not the case. 0x13 means remote has disconnected. My problem is the 0x3D error that ocures after "Requesting to update ATT MTU to.."

My bad I did not make clear the disconnection reason that puzzles me

Dimitris

[DimitrisP]

Hello EvdinI

thanks for reply

I am not concerned about the 0x13 disconnected reason but for the 0x3D that appears after requesting MTU update. Nothing to do with bond data already test that. The phone is not an old one (Android 5+ and BLE4.2). If I use the the uart app from nrf toolbox that also changes the MTU there is no problem. The error happens when I try to bond the device with a passkey and NRF_SDH_BLE_GATT_MAX_MTU_SIZE>23. Immediately after the connection event, nrF stack is trying to change the MTU size and right after that I get the 0x3D disconnection reason. If MTU is selected to be 23 from config.h bonding works fine.

My bad I did not make clear the disconnection reason that puzzles me

Dimitris

[Edvin]

From Wikipedia:

"Android 5.0 was first unveiled under the codename "Android L" on June 25, 2014"

I would say it is a bit old. Of course everything is relative, but we are closing in on the birth of BLE. In addition, I should mention that there were a lot of flaky BLE stacks in different Android phones when this was introduced to phones.

The BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE occurs when a packet has the correct CRC but wrong MIC, so it means that the packet was sent and received successfully, but the key used for encryption is wrong. According to the specification the link should be dropped at this point, for security reasons. Do you have a sniffer trace of this happening? If not, perhaps you could try to capture one using the nRF Sniffer.

As for possible workarounds, assuming it is the phone not being able to keep up, perhaps you could try to wait requesting the MTU > 23 until after the encryption is done? It is at least worth a shot.

What hardware are you running this on? nRF52840 DK? In that case, what version of the DK do you have? If you are running this on custom Hardware, are you able to tell what it says on the nRF52840 chip? What I am after is what revision of the chip you have. I see that we had some issues with BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE, but this was only on the engineering samples (like the ones used on the Preview DK), but that was fixed before the production releases (and official DK).

Best regards,

Edvin