How to resolve random ble address for more than one remote device

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Please help me to understand how to implement the following scenario: my device based on CYW20706 is BLE peripheral that is able to accept pairing from multiple clients and maintain bonding info over power cycles.

According to WBT101-04B-BLE-Ntfy-Sec.pdf document, if bonding info for the remote device being connecting exists, it shall be loaded upon receiving BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT. Now comes the question: the proposed solution is to find the proper bonding info in NV database, based on the MAC address of the remote. However, if the address is random, the one from the database and the one coming with the BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT don't match. I checked the data provided in the wiced_bt_device_link_keys_t structure delivered with BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT, and there only 'bd_addr' (the random one) and 'key_data.le_keys_available_mask' are set. So, there's no chance to find out whether the data from NV database belongs to the remote device being connecting.

However, if we use only one device, it works pretty well: when BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT is received we load bonding data without checking MAC address, and it gets accepted.

I did find some tickets that discuss similar issues, for example, this one https://community.infineon.com/t5/Wi-Fi-Combo/How-to-resolve-random-ble-address/m-p/235008#M17495, but they describe scenario with one remote device only.

For my tests I'm using latest version of ModusToolbox 2.4.0 with Bluetooth SDK 3.1.0 on CYW920706WCDEVAL, with LE_Battery_Service sample application.

0 Likes
1 Solution
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

We had a discussion with our developer team and it was concluded that there will not be any more updates to WICED STUDIO since it is considered as deprecated. Therefore our team recommends you to move to Modustoolbox to resolve this issue. We brought up the two concerns you had in moving to Modustoolbox. Those were addressed as below:

1. MTB lacks BTM_SetDefaultLinkSuperTout() API that is essential to our product.

Infineon:  We will provide official support for this API in the next release of BTSDK (MTB).

2. Our product is already Bluetooth-qualified. Using different SDK would mean new qualification, isn't it?
Infineon: The customer can move to BTSDK/MTB even though they have done the listing. It should make no difference.

Regards,
Bragadeesh

View solution in original post

0 Likes
21 Replies
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

Hello @kf 

I would suggest you to go through the application flow example from peripheral-privacy example available here: https://github.com/Infineon/mtb-example-btsdk-peripheral-privacy  

Hope this will help to you to understand managing multiple device bonding with RPA .

Thanks & Regards,

Anjana

0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hello Anjana,

Thank you for providing the example. However, it seems to have the same problem I was talking about in the description of this ticket: in BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT is looking for matching BLE address, that simply cannot work with random addresses, so the user will be forced to start another pairing.

Also please note that the provided example is not available for my hardware CYW920706WCDEVAL.

Please explain how to find matching link key for BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT.

Best regards,
Konstantin

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

When privacy is enabled in the peer device (RPA), we need to store the resolved address, ie the Identity address of the peer device and not the private address to the bonding table. So, the next time the device connects, we have to look for the matching ID address and not the Private address.  When you connect for the first time, you will receive the BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT event and you will see that you will be adding the ID address in to the bonding table. Also, after reset, you need to add the peer IRK keys to the resolution DB by adding the device to wiced_bt_dev_add_device_to_address_resolution_db (). This will help in resolving the private address from the peer device.

20706 doesn't have an internal flash to store bonding data, therefore you need an external flash to store bonding info.

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Thank you for the answer. Actually, we use CYW920706WCDEVAL for experiments and CYBT-353027-02 in our product. Both of them have flash, so it's not a problem to store link keys over power cycles.

I merged the example provided by Anjana (https://github.com/Infineon/mtb-example-btsdk-peripheral-privacy) into LE_Battery_Service sample application and the random address resolution works on ModusToolbox 2.4.0 with Bluetooth SDK 3.1.0, exactly as you explained.

However, in our product we still use WICED Studio 6.4. I built the same LE_Battery_Service sample application in WICED Studio 6.4, but unfortunately the random address resolution doesn't work. Probably, the Bluetooth SDK used in WICED Studio 6.4 (I couldn't find out what version it is) contains some bugs that got fixed in Bluetooth SDK 3.1.0.

Please tell me how to implement random address resolution support in WICED Studio 6.4.

Thank you and best regards,
Konstantin

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

We highly recommend using MTB for development on CYW20706A2 device. We do not recommend using Wiced Studio since there are no plans to have any bug fixes in the BTSDK of WICED studio. please let us know if you have any issues in moving your development to MTB.

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Unfortunately, we cannot use MTB because it lacks APIs that are essential to our project, e.g. BTM_SetDefaultLinkSuperTout (). Another concern is that our product is already passed Bluetooth qualification, so we cannot simply replace SDK, right?

As far as I understand, the patches for the Bluetooth controller firmware are included in library files delivered with BT SDK. So it must be possible to replace some old libs in WICED with new libs from MTB and get necessary fixes. Could you help me with that?

Thank you and best regards,
Konstantin

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

In CYW20706A2 device, the first used private address of the peer device is used as the identity address of the peer device when pairing for the second time. For subsequent connections, when the peer tries to connect with a different random address, it will be resolved to the first used private address. Therefore you should still be able to match the incoming address with the address in your bonding table. I was able to make this work with the hello sensor example in the WICED Studio. Can you also please test the hello sensor example and check this scenario?

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Sorry for replying late, I was on vacation.Thank you for the explanation. Unfortunately, the fact that it works with hello_sensor example does not prove anything. Our goal is to work with _multiple_ devices, as I explained in the task's name and description. And this does not work. Please see my comment of ‎Dec 20, 2021 02:43 AM.

Best regards,
Konstantin

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf , Can you please share the BTSpy logs showing the issue? Also, during each of the BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT please print the address requested by the peer and the address present in the bonding table. From my experiment, I find both these addresses to be the same during pairing after reset. Also print the address in BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT and while retrieving keys from bonding table after reset to store in addr resolution DB.  Let us see your logs to understand your issue better. Let me know if you have questions.

Regards,
Bragadeesh
0 Likes
lock attach
Attachments are accessible only for community members.
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Please find the BTSpy logs attached. For your convenience I attached Ellisys traces as well. I used LE_Battery_Service sample application with modifications taken from this example https://github.com/Infineon/mtb-example-btsdk-peripheral-privacy in order to support more than one device in the database.

The test case is simple: after flashing the LE_Battery_Service software to CYW920706WCDEVAL, pair 2 mobile phones with the CYW (make sure they don't have previous pairing with the CYW), power off the CYW, power it on and try to connect the phones again. Phone #1 has Android 8, phone #2 has Android 9.
Detailed test scenario
----------------------------------------
1. Flash the software to CYW
2. Delete pairing info with CYW on both phones
3. Use nRFConnect application on Phone #1 and try to read battery status (requires authentication) - this initiates pairing, the pairing succeeds and the battery status  gets read; disconnect the phone
4. Repeat step (3) with Phone #2
5. Power the CYW920706WCDEVAL off, wait 10 seconds, power it on
6. Repeat step (3)
7. Repeat step (4)

This scenario works pretty well if the LE_Battery_Service sample application is being built with ModusToolbox 2.4.0 with Bluetooth SDK 3.1.0 or 3.2.0. However, if I build the application using WICED Studio 6.4, it works up to step (6), but step (7) always fails. That means: if I connect Phone #2 that is already paired with the CYW and try to read battery level, it requests pairing, then the pairing attempt fails and Phone #2 gets disconnected. When I repeat step (7), the 2nd pairing attempt succeeds and I am able to read the battery level. This is 100% reproducible.

Best regards,
Konstantin

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

From what I see in the HCI logs, when the second phone is trying to connect (and pair) after reset, it is not being resolved to it's public address. See log below:

1909 18:48:25.502 D🠈 HCI EVT RCVD [1] Event from HCI. Name: HCI_BLE_Event (Hex Code: 0x3e Param Len: 31)
1910 18:48:25.502 D🠈 HCI EVT HCI_BLE_Enhanced_Conn_Complete_Event : 10 (0x0a)
1911 18:48:25.502 D🠈 HCI EVT Status : 0 (0x00)
1912 18:48:25.502 D🠈 HCI EVT Connection Handle : 64 (0x0040)
1913 18:48:25.502 D🠈 HCI EVT Role (0 = central, 1 = peripheral) : 1 (0x01)
1914 18:48:25.502 D🠈 HCI EVT Peer Address Type : Random (01)
1915 18:48:25.502 D🠈 HCI EVT Peer Address : 5a-7c-de-cd-4a-2f
1916 18:48:25.502 D🠈 HCI EVT Local_Resolvable_Private_Address : 00-00-00-00-00-00
1917 18:48:25.502 D🠈 HCI EVT Peer_Resolvable_Private_Address : 00-00-00-00-00-00
1918 18:48:25.502 D🠈 HCI EVT Conn Interval : 36 (0x0024)
1919 18:48:25.502 D🠈 HCI EVT Conn Latency : 0 (0x0000)
1920 18:48:25.502 D🠈 HCI EVT Supervision Timeout : 500 (0x01f4)
1921 18:48:25.502 D🠈 HCI EVT Clock Accuracy : 1 (0x01)

However,  when the first phone tries to pair after reset, it is being resolved correctly. 

1736 18:48:12.869 D🠈 HCI EVT HCI_RAW Event Data:
1737 18:48:12.869 D🠈 HCI EVT 0000: 0a 00 40 00 01 02 7b 34 f6 f1 6c a4 00 00 00 00 ..@....4..l.....
1738 18:48:12.869 D🠈 HCI EVT 0010: 00 00 6d ef e5 cf bb 4b 28 00 00 00 f4 01 01 ..m....K(......
1739 18:48:12.869 D🠈 HCI EVT RCVD [1] Event from HCI. Name: HCI_BLE_Event (Hex Code: 0x3e Param Len: 31)
1740 18:48:12.869 D🠈 HCI EVT HCI_BLE_Enhanced_Conn_Complete_Event : 10 (0x0a)
1741 18:48:12.869 D🠈 HCI EVT Status : 0 (0x00)
1742 18:48:12.869 D🠈 HCI EVT Connection Handle : 64 (0x0040)
1743 18:48:12.869 D🠈 HCI EVT Role (0 = central, 1 = peripheral) : 1 (0x01)
1744 18:48:12.869 D🠈 HCI EVT Peer Address Type : Public Identity Address (02)
1745 18:48:12.869 D🠈 HCI EVT Peer Address : a4-6c-f1-f6-34-7b
1746 18:48:12.869 D🠈 HCI EVT Local_Resolvable_Private_Address : 00-00-00-00-00-00
1747 18:48:12.869 D🠈 HCI EVT Peer_Resolvable_Private_Address : 4b-bb-cf-e5-ef-6d
1748 18:48:12.869 D🠈 HCI EVT Conn Interval : 40 (0x0028)
1749 18:48:12.869 D🠈 HCI EVT Conn Latency : 0 (0x0000)
1750 18:48:12.869 D🠈 HCI EVT Supervision Timeout : 500 (0x01f4)
1751 18:48:12.869 D🠈 HCI EVT Clock Accuracy : 1 (0x01)

1. Can you please let us know if you are able to pair with both these devices for the second time without a reset?

2. Does it matter the order of phones you try to connect / pair after reset? For example, after reset, did you try to connect (and pair)  the phone#2 (and pair) first and then the phone#1? Did you try the following scenario? Connect (and pair) phone#1, disconnect phone#1. Connect (and pair) phone#2, disconnect phone#2.  Reset device. Connect (and pair) phone#2, disconnect phone#2. Connect (and pair) phone#1, disconnect phone#1.

3. Can you also please attach the project you used for testing. I'm also trying to test this scenario at my end. 

Regards,
Bragadeesh
0 Likes
lock attach
Attachments are accessible only for community members.
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

> 1. Can you please let us know if you are able to pair with both these devices for the second time without a reset?
I guess, your question is: am I able to connect both phones without new pairing after doing steps (1) - (7) and power-cycling the CYW again, right? The answer is: no. The same phone (Android 9) has to be paired every time after the CYW gets powered off.

> 2. Does it matter the order of phones you try to connect / pair after reset?
No. It does not matter in which order I'm connecting the phones. That means, if at step (6) I repeat step (4) and at step (7) - step (3), the problem is the same - the phone with Android 9 has to be paired every time after the CYW gets powered off.

> 3. Can you also please attach the project you used for testing. I'm also trying to test this scenario at my end.
Please find WICED Studio project attached.

Please note that if you build the same application in MTB, the problem does not occur.

Regards,
Konstantin
0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

I guess, your question is: am I able to connect both phones without new pairing after doing steps (1) - (7) and power-cycling the CYW again, right? The answer is: no. The same phone (Android 9) has to be paired every time after the CYW gets powered off.

No, I wanted to check the following scenario. Perform steps 1 to 4. Skip step 5 (do not reset the board). Perform steps 6 and 7. I wanted to check if the issue happens only when we reset the CYW device or if the issues happens for every reconnection of the Android 9 phone (irrespective of power cycle).

No. It does not matter in which order I'm connecting the phones. That means, if at step (6) I repeat step (4) and at step (7) - step (3), the problem is the same - the phone with Android 9 has to be paired every time after the CYW gets powered off.

a) Should we assume the issue happens only when we use Android 9 phone?

b) Were you able to reproduce the issue with some other phone (replace Android 9 phone with some other phone for phone2)? 

c) If I have a single Android 9 phone and perform steps 1,  2, 4 , 5 and 7. Is the issue reproducible?

Please help us answer the above questions to identify the issue.

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

No, I wanted to check the following scenario. Perform steps 1 to 4. Skip step 5 (do not reset the board). Perform steps 6 and 7. I wanted to check if the issue happens only when we reset the CYW device or if the issues happens for every reconnection of the Android 9 phone (irrespective of power cycle).
It happens only after power cycle. It never happens with MTB.

Regarding a), b) and c): I only have those 2 phones. But could borrow an Android 11 phone as well as an iPhone (I guess, it was not the newest iOS), and they showed the same problem. I don't have them right now so I cannot collect logs.

And I'd like to emphasize the fact (again!) that if I build the same software using MTB, it works on the same evaluation board with the same 2 phones! So I find it extremely reasonable to assume that the problem is not related to the hardware I'm using for tests, but rather to bugs in WICED software that were fixed in MTB.

Regards,
Konstantin
0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

I was finally able to reproduce the issue in WICED Studio 6.4. All this while I was doing my testing in WICED studio 6.2. Looks like there has been an error commit in WICED studio 6.4 files that has caused this issue. Can you please perform the test in WICED studio 6.2 and check if the issue doesn't occur.

I was able to see the issue in WICED studio 6.4 but not in WICED studio 6.2 with an Android 11 Phone. Can you also please test this at your end?

https://community.infineon.com/t5/Wi-Fi-Combo/WICED-Studio-6-2-1-has-been-released/m-p/220540

We are checking internally how to revert this commit file. We appreciate your cooperation.

 

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Thank you very much for your efforts! I've just tested it with WICED studio 6.2 and it works just fine with exactly the same test setup.

How should we proceed now? Will there be an official patch to WICED studio 6.4?

Regards,
Konstantin
0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

We have three options here.

1. Recommended: You can move to MTB as this has fixed the bugs and it is the recommended development tool for latest designs. This BTSDK will have the latest bug fixes and any new bug fixes in the future will be done in MTB only. There will not be any more official patch fixes in WICED Studio 6.4. The support for BT devices is deprecated in WICED studio. We can work on porting your project to MTB (highly recommended) and we can look/ request for equivalent APIs from the development team on the new BTSDK. We can help you on any questions that you may have while porting this project. We fully support bug fixes on MTB.

2. Risky: You can use WICED studio 6.2 or copy the folder FW files of CYW20706A2 to WICED Studio 6.4. (WICED-Studio-6.x\20706-A2_Bluetooth\Wiced-BT\tier2\brcm) This works for me. However, the bug fixes that were made in the WICED studio 6.4 from 6.2 will not be available. You may have to retest your entire application and ensure that it works as expected with FW files of WICED studio 6.2.

3. Since there won't be an official fix on WICED studio (as it is fixed in MTB), patch fixes on WICED Studio 6.4 will be considered as special requests and we recommend you (or your Infineon FAE) to create a case on this special request. We will review the request further internally and may be fixed based on priority.

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Thank you again for the comprehensive answer.
1. (a)MTB lacks BTM_SetDefaultLinkSuperTout() API that is essential to our product. (b) Our product is already Bluetooth-qualified. Using different SDK would mean new qualification, isn't it?

2. I agree with you, we shouldn't do that.

3. I've just contacted our FAE regarding this issue.

Best regards,
Konstantin
0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

Thanks for the reply. We already have an API in BTSDK (MTB)"wiced_bt_dev_set_link_supervision_timeout" that sets the supervison time out of a particular connection. Is this acceptable? I'm checking internally if there is a way to set the default supervision timeout.

Regards,
Bragadeesh
0 Likes
kf
Level 3
Level 3
First like received 25 sign-ins 10 replies posted

Hi Bragadeesh,

Of course, we knew about wiced_bt_dev_set_link_supervision_timeout() API. But our application is designed the way it sets link supervision timeout once globally and does not change it. Setting it for every particular connection will require re-design and, what is much more critical, additional testing efforts.

And our biggest concern is: do we have to make new Bluetooth Qualification for our product is we move to MTB?

Best regards,
Konstantin
0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @kf ,

We had a discussion with our developer team and it was concluded that there will not be any more updates to WICED STUDIO since it is considered as deprecated. Therefore our team recommends you to move to Modustoolbox to resolve this issue. We brought up the two concerns you had in moving to Modustoolbox. Those were addressed as below:

1. MTB lacks BTM_SetDefaultLinkSuperTout() API that is essential to our product.

Infineon:  We will provide official support for this API in the next release of BTSDK (MTB).

2. Our product is already Bluetooth-qualified. Using different SDK would mean new qualification, isn't it?
Infineon: The customer can move to BTSDK/MTB even though they have done the listing. It should make no difference.

Regards,
Bragadeesh
0 Likes