[Bug Report] Characteristic encryption & write without response

[Jens Meder]

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

[Carles]

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

[Jens Meder]

Hi Carles,

thanks for the fast reply.

Yepp, with "activate encryption" we mean using OPEN instead of ENC_NO_MITM. Additionally, we set rd_auth and wr_auth, 0 or 1 doesn't matter (the corresponding auth event will be handled accordingly). So if we replace every ENC_NO_MITM with OPEN, throughput is as fast as it should be but with ENC_NO_MITM we get the described behaviour.

I have dug a bit deeper and could narrow down this effect to one particular service. We use HID over GATT (ble_hids) in our application based on the keyboard example. So without HID over GATT service I can confirm that throughput stays the same. If we activate the HID over GATT service, throughput goes down with encryption and write without response, even though no key presses are being sent. Does this service alter connection parameters in any way?

BTW test device is an Apple iPhone 6 Plus with iOS 8.3 .

Thanks,

Jens

[Carles]

with "activate encryption" we mean using OPEN instead of ENC_NO_MITM

You mean the other way around right?

If your throughput changes when you add a service that means that you are not calculating the throughput to that particular HID service, but rather to another one of your own, and it also means that adding the HID service is having some impact different from the change in encryption. Can you verify that, regardless of encryption, the throughput is the same when you don't have the HID service present? If so, as you say, this could be an after effect of using the SDK's HID module. I will check with the SDK team

[Jens Meder]

Oh yeah, sorry, it's the other way around ;-)

And yes, I have verified that without active HID service the throughput stays the same no matter which write mode or type of encryption we set.

Would be good to know if there is any fix for this. For now, we have to reboot and deactivate HID over GATT if we need to send a larger amount of data via write without response.

Thanks for your effort!

[Carles]

This could be then perhaps due to the HID example's management of connection parameter updates. Can you try including the HID service but not calling the conn_params_init() function that comes in the main.c of ble_app_hids_keyboard?