CC2340R5: CC2340R5: prevent re-connection request from central

Hi,

Thank you for reaching out. We will look into this and get back to you. In the meantime, can you share the SDK version you are using?

Best Regards,

Jan

Hi Jan,

Thank you for your reply.

The following is the environment on my side:

• CCS Version                                                    : 12.7.1.00001
• SIMPLELINK-LOWPOWER-F3-SDK Version : 8.10.01.02

Hello,

Thanks for reaching out.

May I ask for you to share more details about the use case? What I understand is that you wish the peripheral to retry entering the passkey to start a paring/bonding process (?) However I don't see how sync the bonded devices with the accept list will help on this. The accept list works as a whitelist and basically allows the devices which addresses are known to connect and receive scan responses. Using Sync Acceptlist With Bonded Devices will first get the accept list cleared and then each unique address stored by bonds in SNV will be synchronized with the accept list indefinitely or until disabled or the maximum number of supported bonds is reached.

BR,

David.

Hi David,

Thank you for supporting.

Use Case:
When the central device sends a pairing request, a passkey popup is displayed.
I want to terminate the authentication and disconnect the temporary connection by invoking GAP_TerminateAuth() → GAP_TerminateLinkReq(). This works without any problems.
On the central side, when the temporary connection established previously is lost, the central device will send a connection and pairing request again to the peripheral.
I would like to use the [Sync Acceptlist With Bonded Devices] feature to ignore/prevent that re-connection request.

Step by Step:

Central: Sends a connection request
→ Pairing popup is displayed.
Peripheral: Invokes GAP_TerminateAuth(), GAP_TerminateLinkReq()
→ Connection is terminated.
Central: Sends a connection request again
→ Pairing popup is displayed again.
Is it possible to use [Sync Acceptlist With Bonded Devices] to prevent re-connection requests from the central device?

If I am wrong, please correct me .

Thank you very much.

Hello,

Thanks for the details, could you please confirm if the devices have paired before before the connections is lost?

BR,

David.

Hi David,

Thanks for the feedback.

The status as below:
1/ A temporary connection has been established.
2/ Authentication has not been completed yet.
→ Devices have not paired yet.

When the passkey popup is displayed on the central device (smartphone),
I didn’t interact with it any further
and sent GAP_TerminateAuth() followed by GAP_TerminateLinkReq() on the peripheral side.

Kind regards,

Hello,

I see, thank you. However, if you haven't bonded before, then when the accept list syncs with the bonded addresses, it will not find it and therefore it will try to pair/bond when re-connect.

BR,

David.

Hi David,

Thanks for your feedback.

I think I  misunderstood the [Sync Acceptlist With Bonded Devices] feature.
Could you please confirm my understanding?

The [Sync Acceptlist With Bonded Devices] feature supports saving bonded device information into a list (accept list or whitelist). 

1/ Accept List Not Full: The device will accept reconnections from both bonded devices in the list and potentially from other bonded devices, even if they are not currently in the accept list. Therefore, reconnection requests will be accepted regardless of whether the requesting device is in the accept list as long as the accept list is not full.

2/ Accept List at Maximum Capacity: Once the list is full, the peripheral restricts reconnections to only those devices explicitly listed in the accept list, which helps control access and limits connections to devices already recognized.

In my case, The Acceplist is NOT FULL and reconnection request is always accepted. 

Hello,

I see, thank you for clarifying. The whitelist (accept list - AL) in general is used to restrict which devices are allowed to connect to your device. If a remote device is not on the whitelist, then it is not allowed to connect. What I understand is that you want to use the whitelist so that after one connection attempt, the devices that are not included there, are then not able to connect. First we need to make sure you have actually set your filter policy to consider the whitelist, this can be done through SysConfig. However, to receive the first connection request, the device should be in the accept list so this might not work for your case.

BR,

David.