CC2640: No LTK requested and saved in SNV.

Sergei,

Thanks for the inquiry. You mentioned BLE 4.2 stack - does it mean the SDK version 4.20 or the BLE version 4.2? I suspect the former but just wanted to confirm.

At any rate, I wonder if secure connections are disabled, which could cause the pDevSecInfo to be zero. The example "Secure Connections" of the GAP Bond Manager reference below shows this configuration.

http://software-dl.ti.com/lprf/sdg-latest/html/ble-stack-3.x/gapbondmngr.html#gapbondmgr-examples-for-different-pairing-modes

The pairing process that goes successfully AND stores the data in the NV memory would flag the state  GAPBOND_PAIRING_STATE_BOND_SAVED in the function SimplePeripheral_processPairState() of the <simple_peripheral.c> file. A breakpoint or watchpoint there could help verify if the bond is indeed successful (although you seem to already have another reporting mechanism).

I will try to find additional details that may be influencing the ability to have long term bonding enabled and report back.

Hope this helps,

Rafael

Hi Rafael,

Thanks for your reply.

That's correct, the BLE version is 4.2, the SDK version is TI-BLE-Stack-2.2.2.0.

The security flag is set and we can see it in the device SMP response: Bonding Enabled - MITM Disabled - SC Enabled - Keypress Disabled - CT2 Disabled.
I actually tried both: GAPBOND_SECURE_CONNECTION_ALLOW and GAPBOND_SECURE_CONNECTION_ONLY, none of them helps.

I traced 4.1 (SDK TI-BLE-Stack-2.1.0.3) and the SMP response from the device has key distribution list value 0x3:
'Initiator Key Distribution: 0x03 - LTK IRK Requested'. It looks to me that this field in the message is set somewhere in a lower protocol layer before sending it.
And it ignores the parameters I provide for the message. I've tried different combinations but the value is always 0x02.

I will keep trying different configurations and debugging, and will let you know if I find something.

Thanks,
Sergei.

Hi Rafael,

I debugged it a bit more and see that in SM_StartPairing it skips smGeneratePairingReqRsp due to some zero value in the authentication parameters, provided to the function. It's hard for me to say from the disassembly what caused it. It gets some GAP parameters earlier in the function, those values can cause the issue.

It would be very helpful If you can take a look at the code and tell me what GAP parameters it's using, and I will double check their values.

Thanks,
Sergei. 

Sergei,

Please apologize for the delay. I was sidetracked and will address the first thing on Monday.

Regards,

Rafael

Hi Rafael,

I think the place I described in my previous post is not the actual one, where it builds the pairing request/response.
In that place it just checks the key length with MIN and MAX values and exists. It continues processing the pairing request event later.
At some point it calls smSetPairingReqRsp where it uses parameters pre-allocated in the heap (in my case the address is 0x20001978) to fill up the response also allocated in the heap at 0x20002af8. The keyDistList value there is 0x02 which means it asks only for IRK.

I think we should understand how it builds the parameters and what causes the value not to include LTK into the list.

Thanks,
Sergei.

Sergei,

The Security manager usually interfaces through the GAP Bond Manager, therefore I am debugging a level up from you to try to find a combination of factors accessible by the user to reproduce the problem. The flags on my system match yours (MITM disabled, Bonding, etc.) and at the point of authentication I have the following flags:

At the moment am trying to reproduce the failing pairing "retention" bonding here in my setup to no avail so far - it always saves the bonding to the SNV memory. That is, as long as I keep the GAPBOND_BONDING_ENABLED set. I can see this when I get to the point of adding the bonding to the SNV, where the function gapBondMgrAddBond() shows a valid LTK.

I don't have an apple device (where PacketLogger is being hosted right?) and I am pairing with an Android device and connecting using the application LightBlue. i don't think this should matter (well, hopefully not).

I hope this helps take you a bit further on the debug process.

Regards,

Rafael

Hi Rafael,

Thanks for your response.

You are right, I think I have gone a bit further because at the point you are showing at the first screen shot everything looks good:
when it calls GAP_Authenticate(&params, pPairReq); the key distribution flags set properly to 0707: LTK, IRK, Sign.
But when the stack builds the actual response message in smSetPairingReqRsp it somehow ignores this list and sets only IRK flag to be sent to the central. Thus the central send send only IRK key back to the peripheral and when it comes to gapBondMgrAddBond the pAuthEvt->pSecurityInfo pointer is NULL.

Can you please put a breakpoint at smSetPairingReqRsp and try to see where it takes the flags from and why it doesn't set LTK flag in the response message?

I also use LightBlue or BlueSee with Mac or iOS for testing and I think the problem is on the peripheral side, something is misconfigured there.

Thank you,

Sergei.

any news upon this?

This was expected behavior as:

"2.4.3.2 LE Secure Connections key distribution" only allows IRK and CSRK key distribution.
MITM must be enabled for LE SC.

I hope it helps,

Sergei.