LP-EM-CC2340R5: Queries - Directed Advertisement

Hello Prince,

Thanks for reaching out.

Could you please specify what SDK you are using?

I am working on reproducing the issue on my side. I have modified the basic_ble code so that RPA is updated every 60 sec and I am using a Bluetooth sniffer to see the address update. So far I can see that before and after disconnection the RPA value keeps updating correctly on the sniffer logs.

Could you please help me with the following questions?

1. From your explanation, the Central is TargetA and Peripheral the AdvA right?
2. Are you using the SimpleLink Connect App from Texas Instruments or is it a custom app?
3. How do you know the RPA on the Target (Central device I assume) is not getting updated?
4. Are you not able to connect again to the peripheral from the phone using the SimpleLink App after RPA updates?

BR,

David.

Hi David,

I am using simplelink_lowpower_f3_sdk_7_20_00_29. I am using directed connectable advertisement mode in Basic BLE Peripheral.

1. AdvA is CC2340's RPA in the direct connectable advertisement packet. TargetA is smartphone's RPA in the direct connectable advertisement packet.

2. I am using nRF Connect app

3. I am talking about peripheral side only. After bonding, I disconnected CC2340 from my smartphone(Central) . CC2340 started advertising with directed connectable advertisement packets. Smartphone using RPA with public Id, I configured CC2340 address mode as RPA with public Id. So in directed connectable advertisement packet AdvA and TargetA fields are now RPA.

Now I configured Basic BLE peripheral to update RPA in every 1 min. Here I attaching 2 snapshots.  Two subsequent RPA changes over AdvA field.

img1

img2

Here you can see only AdvA field is getting updated after 1 min. But TargetA field is not getting updated.

4. I successfully connected again. There is no issue. Here another information is that TargetA field is getting updated after every reconnection. Here I attached the sniffer log

img3

That is AdvA field is updated every 1 minute (configured RPA update interval) and TargetA field is updating after every connection. This is my observation.

Regards,
Prince

Hello Prince,

Thank you for the information.

I see, it is possible that the target device is not updating the RPA address until a new connection event. I can reproduce the same behaviour on my side with the sniffer. Please allow me until Monday to provide an answer on this.

From where are you reading the RPA address using the CC2642 as a sniffer?

BR,

David.

Hi David,

For displaying CC2642 sniffer logs I am using Wireshark.

Regards,
Prince

Hello Prince,

Thanks for the patience.

This is an expected behaviour related to the privacy feature of the RPA. This privacy feature inhibits tracking from untrusted peer devices. The addresses it uses are generated with an Identity Resolving Key which is exchanged between devices during bonding phase. Therefore, the connection between peripheral and target will remain but external devices (sniffers) will not be able to track the device further after the address has been modified. That is why they will appear as new devices with new addresses, visible only after a new connection is established.

Please see more information about it on our users guide (Resolving Private Addresses)

Let me know if this clarifies the observations.

BR,

David.

Hi David,

If connection is not established, then TargetA field will be constant.

Suppose device is advertising forever and no connection established. In this state, the external devices (sniffers) can track our device with this static targetA field. In this case, device will lose its privacy due to static targetA field.

How we can avoid this? Can you please give some suggestions?

Regards,
Prince

Hello Prince,

What is the frequency at which the central device (TargetA address) is also updating its RPA? Is it also every minute?

BR,

David.

Hi David,

TargetA field is part of Peripheral device advertising data in directed advertising. The RPA in the TargetA field(generated by peripheral device using central device's IRK) and RPA of central device(generated by central device with using its local IRK) are not same. 

The RPA used by the central device to send Scan request and connection request is getting updated every 15 minutes. We turned off central device. From this moment the peripheral device using same RPA on TargetA field of directed advertisement.

Regards,
Prince

Hello Prince,

I am checking this with the team and working on reproduce the same situation on my side today. Please bear with me.

BR,

David.

Hi David,

Friendly reminder.

Regards,
Prince

Hello Prince,

Apologize for the delay, I am still working on reproducing the issue and reading the TargetA value with the ble sniffer.

Please allow me until Monday to provide an answer, it may happen that this will have to be look at by our R&D team. Could you please share the modifications you did to your Sysconfig file for directed adv (peer address)?

BR,

David

Hi David,

I have not modified the sysconfig. For this purpose I configured NVS, and stored identity address and address type. Read Identity address and address type using linkDB_GetInfo function, and write it to the NVS I configured.

When device wake up next time, on Peripheral_start function application will read the  identity address and address type from NVS region and set it to the advertisement initialisation parameters.

bStatus_t Peripheral_start()
{
    bStatus_t status = SUCCESS;

    status = BLEAppUtil_registerEventHandler(&peripheralConnHandler);
    if(status != SUCCESS)
    {
        // Return status value
        return(status);
    }

    status = BLEAppUtil_registerEventHandler(&peripheralAdvHandler);
    if(status != SUCCESS)
    {
        return(status);
    }

    NVS_Read(&test1); // Read the device identity address and address type stored in NVS. NVS write done in the BLEAPPUTIL_PAIRING_STATE_BOND_SAVED event

    advSetInitParamsSet_1->advParam->eventProps = GAP_ADV_PROP_CONNECTABLE | GAP_ADV_PROP_DIRECTED | GAP_ADV_PROP_LEGACY;
    memcpy(advSetInitParamsSet_1->advParam->peerAddr, test1.peerDeviceAddr, sizeof(B_ADDR_LEN));
    memcpy(&advSetInitParamsSet_1->advParam->peerAddrType, &test1.pPeerAddrType, sizeof(test1.pPeerAddrType));

    status = BLEAppUtil_initAdvSet(&peripheralAdvHandle_1, &advSetInitParamsSet_1);
    if(status != SUCCESS)
    {
        // Return status value
        return(status);
    }

    status = BLEAppUtil_advStart(peripheralAdvHandle_1, &advSetStartParamsSet_1);
    if(status != SUCCESS)
    {
        // Return status value
        return(status);
    }

    // Return status value
    return(status);
}

Regards,
Prince

Hello Prince,

Understood.

Does this means that the first connection is done under "Connectable and scannable undirected" mode?

The peerDeviceAddr and pPeerAddrType read from NVS are RPA related?

BR,

David.

Hi David,

David said:

Does this means that the first connection is done under "Connectable and scannable undirected" mode?

Yes.

David said:

The peerDeviceAddr and pPeerAddrType read from NVS are RPA related?

No. I read it after getting bond saved event.

Prince John said:

Read Identity address and address type using linkDB_GetInfo function

I am using this function. We are getting Identity address in this point.

Regards,
Prince

Hello Prince,

Thanks. Please allow me this week to review this with our R&D team and see if we can come back with a quick work around before a more temporary fix is applied if required.

If its possible for you to share the same image (.hex) you have to test it under the same conditions and with our Bluetooth sniffer, I would also appreciate it.

Thanks for the patience.

BR,

David.

Hi David,

Yes, I implemented directed advertisement in Basic BLE example. So I can share it with you. 

But, how I can share it with you ? 

Regards,
Prince

Hello Prince,

After building the project, you can attach the .hex file from the Release folder here (if it is not considered private or confidential information).

Thanks.

David.

Hi David,

We archived the .hex file and uploaded in here.  /cfs-file/__key/communityserver-discussions-components-files/538/direct_5F00_adv_5F00_hex.zip

Regards,
Prince

Hello Prince,

Thank you. I am already discussing this with the team.

Although there is no specific definition on the ble spec of how often the TargetA address should be updated. "The TargetA field of the connectable directed advertising event PDU is generated using the Peer IRK value and the Resolvable Private Address Generation Procedure. The TargetA field uses the public or static device address of the peer device if no peer IRK is available. When an advertiser receives a connection request that contains a resolvable private address for the initiator’s address (InitA field), the Link Layer shall resolve the private address." However I am discussing with the team what are the consequences of the TargetA address remaining the same between connection events.

BR,

David.

Hello Prince,

So far I have reviewed the directed adv with RPA functionality and tested a peripheral device configured with an IRK and I can see the stack is actually modifying both addresses at InitA and TargetA without the need of a connection event. I am testing your file with a ble sniffer and see if the difference maybe due to the fact of how we are fetching the data with the CC26 device.

Thanks for the patience.

BR,

David.

Hi David,

What is the 1.28 s at each log? 
This is the sniffer log of the shared file right? That means those 3 logs are captured at 15 minutes interval?

Regards,
Prince

Hello Prince,

It is a different test I did with a peripheral device to validate both addresses are changing at the same time.

I am running now the tests with your hex file and reviewing the results with a ble sniffer.

The steps I am taking are:

1. Connect to mobile application (SimpleLink Connect).
2. Reset device.

However I don't see a bonding request from the peripheral, not sure if this is enabled from the central then. No directed advertisement is spotted using the sniffer. Am I running the steps correctly here?

BR,

David.

Hi David,

We tested CC2340 application with SimpleLink Connect app.

David said:

The steps I am taking are:

1. Connect to mobile application (SimpleLink Connect).
2. Reset device.

1. Connect from phone
   1. Open tera term, and find the RPA address from tera term
   2. Due to no name given in advertisement data, we have to find the device which have same RPA from tera term
2. After connecting, click the Lock icon in the app window (A pop up will ask for pair, enable pair, Now SimpleLink Connect app will paired and bonded)
3. Now turn off Bluetooth from phone (SimpleLink Connect app doesn't have an disconnect button)
4. This time, CC2340 application will start direct advertising.

Regards,
Prince

Hello Prince,

I am following the steps. A connection is established but I cannot initiate a bonding process from the central side (Simple Link Connect App or nrf) and no services seem to be available.

This happens in both mobile applications.

BR,

David.

Hi David,

We tested with android phone. Today we checked with iPhone. Our iPhone is also not able to pair and bond to this CC2340 application. But android devices are working fine with this CC2340 application.
Can you test with an android phone.

Regards,
Prince

Hello Prince,

Thanks for the information. I am testing with the android phone.

Could you please confirm you are resetting the cc23xx device after first bond?

The RPA is configured to change every 15 mins?

BR,

David.

Hi David,

After first bond, I disconnected BLE connection from phone. RPA update interval is 15 mins.

Regards,
Prince

Hello Prince,

Thanks.

I can see that the TargetA address is also not changing at the same time as the InitA address.

However, as I mentioned on the previous test, the stack is modifying both values.

This pseudo-code shows a bit how this is handled:

I am wondering here if one of these two if cases is not being fulfilled on an application level.

Can you please share how you are reading and saving the RPA information into the NVS during the first connection?

BR,

David.

Hi David,

The peer info read and write to nvs are as follows:

The nvs read and directed advertisement configurations are as follows:

The NVS read and write implementation as follows:

int_fast16_t NVS_Read(Peer_Info *pData)
{
    return (NVS_read(nvsHandle, 0, pData, sizeof(Peer_Info)));
}

void NVS_Write(Peer_Info *pData)
{
    NVS_write(nvsHandle, 0, pData, sizeof(Peer_Info), NVS_WRITE_ERASE | NVS_WRITE_POST_VERIFY);
}

The NVS driver Configuration is done as follows:

Regards,
Prince

Hi Prince,

The subject expert who can best address your inquiry is out of office for the holidays. After returning in early January, they will review your post and provide an initial response within 24 hours.

To ensure quick and efficient resolution of your problem, please make sure you have provided all relevant information related to your request. This may include: SimpleLink SDK version and its dependencies, hardware used, examples being referenced, and steps to reproduce the issue. Please also provide any debug information, screenshots, code snippets, or terminal logs which may help further identify the issue.

Regards,
Jan

Hi Jan,

Please find attached snap of sniffer log with description. This snap will explain the behaviour of our application. You can refer the time stamp in sniffer log. Here we configured RPA update interval as 1 min.

• This test is done on newest CC2340 SDK (version 7.40.0.64) + CC2340 Launch Pad
• Sniffer Log is captured using Wireshark + CC26x2 Launch Pad
• Peer device is Samsung Galaxy F12
• .hex file uploaded here /cfs-file/__key/communityserver-discussions-components-files/538/direct_5F00_adv_5F00_basic_5F00_ble_5F00_basic_5F00_pkg_5F00_v7_5F00_40.zip
• Code snippets are provided in previous chats

Sniffer Log is :

Here we can see our application updating RPA on TargetA field after a disconnection, but not after RPA update interval 1 minute. We believe this will prove our application have access to valid IRK of peer device. 

Regards,
Prince

Hi Prince,

Is this the same issue in this thread: LP-EM-CC2340R5: Queries - CAR and RPAO characteristics - Bluetooth forum - Bluetooth®︎ - TI E2E support forums?
If so let's please keep this to one thread. 

After speaking to R&D, this very well may be a bug. I have filed a ticket will get back to you once I have more information.

Best,

Nima Behmanesh

Hi Nima,

• These thread is about why RPA on TargetA field is not changing even after RPA update period.
• The other thread is about why RPA is getting used in TargetA field if there is no CAR characteristics present in Central role device. And also about vulnerability of device privacy mode.

So we think, these 2 threads should be different is better.

Regards,
Prince

Hello,

Thank you for the clarification, I'll continue working on the threads separately. I've created a ticket to R&D to look into this further. I'll give you an update next week.

Best,

Nima Behmanesh

Hi Prince,

After speaking to my colleague, we'll need to take a step back here as well.

The TargetA field will not update since there's no way of knowing whether or not the Central has changed it's RPA without someway of communicating that to the peripheral. This is why you're not seeing the targetA address update until a reconnection. Having said that, what is the use-case and purpose of using directed advertising here?

Best,

Nima Behmanesh

Hi Nima,

When we were testing our application with BLE Central (Phone) the Target RPA field will get update if we connected and disconnected again and again. That is after every connection Target RPA get updated. You can confirm this with the hex file attached in previous message.

So why Target RPA should change after a disconnection every time ?

Does modifying RPA update time using GAP_SetParamValue API have impact on Target RPA or only on AdvA field ?

Regards,
Prince