This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

[Bug Report] Characteristic encryption & write without response

Hey,

we encounter very strange behaviour when using encryption (without MITM) in conjunction with write without response. If characteristics are unencrypted (open), write without response behaves as expected and is significantly faster than write with response (as it should be). Yet, if we activate encryption, this behaviour inverts, meaning the data comes in significantly slower when using write without response. We have tried different values for the connection parameters (min connection interval, etc.) but behaviour stayed the same.

For now we have a workaround but you might want to have a look at it. We use a NRF51422 QFAA v2 with softdevice 310, NRF51 SDK 7.2.0, and the GCC toolchain.

Thanks in advance,

Jens

Parents
  • Hi there,

    I just ran a quick test locally (on the s130 SoftDevice, but they should be functionally equivalent) and I alternated between:

      BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
      BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
    

    and

      BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.read_perm);
      BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.write_perm);
    

    and then transferred a large amount of Write Command packets to this attribute (always with encryption enabled on the link, that is, always after a BLE_GAP_EVT_SEC_INFO_REQUEST/ BLE_GAP_EVT_CONN_SEC_UPDATE event pair) and got exactly the same throughput regardless.

    There must be something else that is changing in your case.

    Are you setting authorization at all? (rd_auth, wr_auth)

    When you say "activate encryption" in your message, do you mean encrypting the link or using BLE_GAP_CONN_SEC_MODE_SET_ENC_<> instead of _OPEN ?

    Thanks,

    Carles

  • Hey Carles,

    sorry for the late reply.

    We were able to narrow the source of the problem down to the ble_hids module/service of the sdk. We used parts of the keyboards example from the sdk examples folder (only the initializer parts for the ble_services and hid pages table). If we comment out the whole hid over gatt part or use SET_OPEN for all HID characteristics, everything works fine. We have tried various settings for the connection parameters (min/max connection interval etc.) but the problem persists. So our best guess at the moment: there might be something wrong with the ble_hids module in the sdk.

    For now we use a workaround to circumvent the problem (basically rebooting with deactivated hid over gatt if we need higher throughput).

Reply
  • Hey Carles,

    sorry for the late reply.

    We were able to narrow the source of the problem down to the ble_hids module/service of the sdk. We used parts of the keyboards example from the sdk examples folder (only the initializer parts for the ble_services and hid pages table). If we comment out the whole hid over gatt part or use SET_OPEN for all HID characteristics, everything works fine. We have tried various settings for the connection parameters (min/max connection interval etc.) but the problem persists. So our best guess at the moment: there might be something wrong with the ble_hids module in the sdk.

    For now we use a workaround to circumvent the problem (basically rebooting with deactivated hid over gatt if we need higher throughput).

Children
No Data
Related