Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Edvin — Tue, 24 Apr 2018 07:09:42 GMT

Hello,

Sorry for the late reply. I was out of office the previous week.

I talked to some guys who worked on serialization. He told me that the LESC command should be available through the serialized interface in the latest SDK-release. It's only some nrf_soc API's that are not included in the serialization at this point in time.

Best regards,

Edvin

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Ben — Tue, 17 Apr 2018 22:35:23 GMT

Edvin:

Has this issue been fixed in the newly released SDK15?

I looked through the release notes but couldn't find a specific notice that seemed applicable to crypto and serialization.

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Ben — Tue, 13 Feb 2018 15:32:24 GMT

Edvin:

At this point I think we're a little too far along to pivot away from serialization, though I'll consider that for future projects. For this project I can manually implement the RNG by gathering entropy from other sources, so while I wish it could be serialized, I'm not too worried about it.

Do you have an estimate for the release of the next Library update? I've added my email address to my profile if you can send it to me put would prefer not to post it publicly. (I understand that any provided estimate isn't a guarantee, it would just help me decide whether to manually implement the softdevice calls or wait for the update).

Also, you're saying I should be able to edit the nRF5 SDK / Library on the STM32 and modify the counterpart calls in the nRF firmware without modifications to the SoftDevice blob?

I did not have the logging module enabled at that point, but will update this thread when I've repeated the tests.

Thanks

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Edvin — Tue, 13 Feb 2018 08:39:11 GMT

Hello Ben,

I spoke to some people working in with the serialization library. As I mentioned, there seems to be some of the API for LESC that is not serialized, as mentioned in this thread. It has been fixed, but the fixed version has not yet been released. They also said that the Random Number Generator is not serialized. It will either be possible to do this yourself, since random numbers are sort of the back bone in encryption.

Alternatively, instead of using serialization, you should consider to create your own UART protocol, without using the serialization library. This way the nRF would be in control of all BLE related operations, and you can pull requests or push any info you need between the two chips.

If you want to use the serialization you can either wait for the next softdevice release, or try to implement the missing softdevice calls.

Do you get any information from the logging module on the application chip (STM) when the pairing fails? That is around packet #95982 in the sniffer log?

BR,

Edvin

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Edvin — Fri, 09 Feb 2018 13:51:18 GMT

Hello Ben,

I have looked a bit into this. I am not too familiar with the LESC procedure, but I see that it seems to be some serialization API missing for the LESC. I have to check around if someone knows if this is supposed to be working now. Ideally, it would have serialized the RNG, so that you would not need that on the STM.

Let me come back to you on Monday.

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Ben — Thu, 08 Feb 2018 20:20:00 GMT

Hey Edvin,

Yes, the STM+nRF is peripheral / slave.

This is a work computer with Windows 7. For testing on Windows I'm using Win 7, nRF Connect, and a PCA10040 instead of an off the shelf USB Bluetooth adapter. But I'm also at a loss for why it wasn't working when connecting to nRF Connect on iOS.

I programmed the PCA10040 with the ble_app_multirole_lesc and everything worked as expected. I'm not sure what the best way to program my board without using serialization would be, so I haven't. (The only thing I could think was to try to program the nRF on my board with the ble_app_multirole_lesc program, but I'm not sure what that would really be testing).

With Serialization, I can't compile if I don't make the modifications to nrf_drv_rng as I don't have that nrf_rng peripheral on the STM32.

I've attached the Wireshark sniffer from my attempt to connect with iOS / nRF Connectdevzone.nordicsemi.com/.../lesc_5F00_error.pcapng

RE: Serializaiton: sd_ble_gap_lesc_dhkey_reply returns NRF_ERROR_INVALID_STATE with BLE_GAP_SEC_STATUS_UNSPECIFIED during Just Works Bonding...

Edvin — Wed, 07 Feb 2018 09:22:54 GMT

Hello Ben,

I assume that the STM+nRF acts as the peripheral/slave, is that correct?

I think that Windows does not yet support LESC. At least it didn't do in May, as @Rocky posted in this thread. This should however not mean that it shouldn't work in nRF Connect

Have you tried to do this with a "bare nRF" example, without serialization? Just for debugging purposes, that is. Thus also, without removing the nrf_drv_rng drivers, and rewriting nrf_crypto_sw_rng.c and ecc.c?

You can try the example from SDK\examples\ble_central_and_peripherals\ble_app_multirole_lesc

BR,

Edvin

I see from the screenshot of the sniffer log that it is the Master/central that sends the first pairing failed: unspecified reason. Could you post the sniffer log file?