BLEGapSecStatus.confirm_value on passkey bonding.

[mstratford_c]

Hi all, I'm trying to implement passkey bonding using pc-ble-driver-py.

It doesn't appear to be supported in the BLEDriver.py itself, so I tried to add the sd_ble_gap_auth_key_reply call to pc-ble-driver myself.

I'm using:

    @NordicSemiErrorCheck
    @wrapt.synchronized(api_lock)
    def ble_gap_auth_key_reply(self, conn_handle, key_type, key):

        assert (driver.BLE_GAP_AUTH_KEY_TYPE_PASSKEY ==
                key_type)
        print( util.list_to_uint8_array(key))    
        print( util.list_to_uint8_array(key).cast())   
        return driver.sd_ble_gap_auth_key_reply(
            self.rpc_adapter,
            conn_handle,
            key_type,
            util.list_to_uint8_array(key).cast())

And feeding in:

input_val = map(ord,raw_input("Enter passkey: ")[:-1])

As far as I can see, i'm sending it a list of ASCII characters of 6 bytes, removing the null terminator (as per https://github.com/NordicSemiconductor/pc-ble-driver/blob/971241c19abc33bbc6469e1be601a2ab78fbb35b/src/sd_api_v5/sdk/components/softdevice/s132/headers/ble_gap.h#L1183)

I'm getting a auth_status returned of (BLEGapSecStatus.confirm_value), as far I can see that's an error telling me I have fed it an incorrect passcode?

What am I doing wrong?

Cheers!

[Einar Thorsrud]

Hi,

This looks sensible, though I have not tested myself. What is the auth_status you get?

[mstratford_c]

The auth_status returns as BLEGapSecStatus.confirm_value according to the driver. All I can see is infocenter.nordicsemi.com/.../group___b_l_e___g_a_p___s_e_c___s_t_a_t_u_s.html

[mstratford_c]

Hi there, I've just checked this, it's giving me a 6 element array of 0x30-0x39, as required. I'd like to mention, this code did/does work perfectly with the old nrf51-ble-driver_win_0.5.0. Given I've tried this with multiple Bluetooth devices, of which work fine with passcodes on my phone, I think it's an issue with the Softdevice / DLL driver layer provided with the python pc-ble-central-py PIP/github package. Cheers.

[Einar Thorsrud]

I see. Can you debug on the nRF side, and see if all looks good in conn_mw_ble_gap_auth_key_reply() in conn_mw_ble_gap.c?

[mstratford_c]

Hi there, i'm not seeing an obvious instructions for building those into some firmware I can debug in Keil 5? Could you elaborate a little more please? Cheers!

[Einar Thorsrud]

Hi,

I was wondering if you could debug on the nRF side, which is based on the SDK connectivity firmware with some patched from the pc-ble-driver. How to patch it and build it is described here. I do not expect there to be any issues on that side though, as the connectivity firmware itself and pc-ble-driver support passkey entry and that works. This can easily be verified by simply using nRF Connect Bluetooth Low Energy, which uses pc-ble-driver (with the js wrapper) under the hood.

[mstratford_c]

Hi, I'm just getting back to working on this again. Is there a way to see from the Nordic SDK (I'm using a nrf52 dev board running the glucose service peripheral example in SDK 15.2) to see what the other side is receiving pass-code wise? As far as I can see it's hidden within the softdevice itself. I can confirm that NRF Connect on PC with passcode bonding works fine. As far as I can see, ble_adapter.py does all this in the authenticate() function correctly. www.nordicsemi.com/.../group_ble_gap_central_bonding_pk_periph_oob_msc

[Einar Thorsrud]

Hi,

The passkey is forwarded to the SoftDevice by the connectivity firmware running on the nRF device (which receives it via UART from the pc-ble-driver). I was interested in checking the pass key at this point. It should be corrupted already here, since we know that the pc-ble-driver and connectivity firmware itself works (by using nRF Connect). You could verify by debugging or adding some logging in conn_mw_ble_gap_auth_key_reply() in the connectivity firmware? Perhaps seeing how the passkey is corrupted could give some hint.