Max packet size when using bonding

[kurtovic]

I've been trying to implement bonding and encryption into the ble_app_uart example, and realized that the issues I've been running into were caused by the following configuration.

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

Once I changed the values to match the ble_app_gls example, I was able to see successful bonding performed.

#define NRF_SDH_BLE_GAP_DATA_LENGTH 27
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23

These are the security parameters I'm using:

#define SEC_PARAM_BOND                  1                               /**< Perform bonding. */
#define SEC_PARAM_MITM                  1                               /**< Man In The Middle protection required (applicable when display module is detected). */
#define SEC_PARAM_LESC                  1                               /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS              0                               /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_DISPLAY_ONLY    /**< Display I/O capabilities. */
#define SEC_PARAM_OOB                   0                               /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                               /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16                              /**< Maximum encryption key size. */

devzone.nordicsemi.com/.../nrf52-bonding-error-4352-while-trying-to-bond-with-a-cots-medical-device-wearable

The above thread is what made me try changing the values, but I would like to get a response from Nordic on the matter. Are the lower values required when bonding + encryption is implemented? 

I'm working around this limitation by sending data in 20B chunks, but I wouldn't mind going back to the larger size if possible. I'm anticipating that is a consequence of the secure connection, but just wanted to be sure.

[Maria Gilje]

Hello,

I am looking into this.

Best regards,

Maria

[kurtovic]

Hi,

I believe I must have overlooked some other error after getting successful bonding. I'm able to revert back to the original values of 251/247, and everything appears to be working as expected still (even after deleting bonds).

Sorry for the mistake

[kurtovic]

Hi, 

My last post was a false-positive, I must have misinterpreted log output and thought bonds were succeeding with the increased values of 251/247.

Here is a sample of the log output from the nrf52840 running peripheral/ble_app_gls while I try to bond via the nRF connect app.

With data length = 27 and mtu = 23, I see the pairing prompt on the app.

<info> app_timer: RTC: initialized.
<debug> nrf_ble_lesc: Initialized nrf_crypto.
<debug> nrf_ble_lesc: Initialized nrf_ble_lesc.
<debug> nrf_ble_lesc: Generating ECC key pair
<info> app: Glucose example started.
<info> app: Fast advertising
<debug> nrf_ble_gq: Registering connection handle: 0x0000
<info> app: Connected
<debug> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
<info> app: Passkey: 872149
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding
<info> app: Link secured. Role: 1. conn_handle: 0, Procedure: 1
<debug> nrf_ble_lesc: Generating ECC key pair
<info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0 bond=0x1 lv4: 0 kdist_own:0x3 kdist_peer:0x3
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<debug> nrf_ble_gq: Processing the request queue...
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update

With data length = 251 and mtu = 247, the app connects but never shows the pairing prompt

<info> app_timer: RTC: initialized.
<debug> nrf_ble_lesc: Initialized nrf_crypto.
<debug> nrf_ble_lesc: Initialized nrf_ble_lesc.
<debug> nrf_ble_lesc: Generating ECC key pair
<info> app: Glucose example started.
<info> app: Fast advertising
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<debug> nrf_ble_gq: Registering connection handle: 0x0000
<info> app: Connected
<debug> nrf_ble_gq: Processing the request queue...
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: Fast advertising
<info> app: Disconnected

The app shows error 129 (0x81) GATT INTERNAL ERROR, and 133 (0x85) GATT ERROR for the latter configuration.

Edit: Updated the second log with DEBUG log level since it was missing originally.

[kurtovic]

Hi,

I have figured out what has been going on. It turns out the issue is isolated to the device I've been running the nRF Connect app on (it is a very old tablet). If I attempt the same procedure using a more up-to-date mobile device, I have no issues pairing when using the 251/247 configuration.