This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: Problem with directed advertising with a paired peer's public address

Part Number: CC2642R

Hi,

Since there hasn't been no response to the original thread(https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/785065), I created a new thread. The problem description is found in the original thread.

This is my workaround. I modified gapBondMgr_SupportsCentAddrRes() as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
static uint8_t gapBondMgr_SupportsCentAddrRes(uint8_t *pPeerAddr,
                                              GAP_Peer_Addr_Types_t addrType)
{
  uint8_t idx;
  // Check for valid input address
  if(pPeerAddr == NULL)
  {
    return FALSE;
  }
  // Try to find this device in the resolving list to see if an RPA will be
  // used
  if(MAP_LL_PRIV_FindPeerInRL(resolvingList, addrType, pPeerAddr) !=
     INVALID_RESOLVE_LIST_INDEX)
  {
    // Device was found with a valid IRK. If the IRK is not all zeros,
    // RPA will be used. So, check to see if the device supports central address
    // resolution (i.e. it has the CAR char).
    // First, find the bonding table index:
    if(GAPBondMgr_FindAddr(pPeerAddr, addrType,
                           &idx, NULL, NULL) == SUCCESS)
    {
      // Read the IRK from NV
      uint8_t tempIRK[KEYLEN];
      osal_snv_read(DEV_IRK_NV_ID(idx), KEYLEN, tempIRK);
      
      // Check if the device has CAR enabled or the IRK is all zeros
      if((gapBondMgrGetStateFlags(idx) & GAP_BONDED_STATE_CAR) ||
         osal_isbufset(tempIRK, 0x00, KEYLEN))
      {
        // Device has CAR enabled or doesn't have to have it,
        // so OK to use RPA or IDA
        return TRUE;
      }
      else
      {
        // Device doesn't have CAR enabled so can't use RPA
        return FALSE;
      }
    }
    else
    {
      // Device wasn't found in bonding table. This means that the device was
      // manually added to the resolving list by the application and it is the
      // application's responsibility to check the CAR.
      return TRUE;
    }
  }
  else
  {
    // An RPA won't be used so no need to check for CAR char
    return TRUE;
  }
}

The workaround works on a TI Peripheral which is trying directed advertising towards TI Central initialized with ADDRMODE_PUBLIC and paired with the TI Peripheral.

Can somebody from TI please confirm if the idea makes sense?

- Cetri

  • Hi,
    To refer to the answer in the other thread "I created an internal bug ticket for the development team. From our side the case is pending review for the Q2 release planning". I'm assigning the same expert to validate your workaround.
  • Cetri,

    Not sure I follow exactly.
    1) When is the IRK all zero? IRK distribution could happen even without privacy or network privacy
    2) Given 1) what happens when the device does not have CAR, but has distributed IRK != 0 and we want to direct advertise using the public address which is what it's using?

    It seems to me that the issue in the original thread was caused by the supportsCentralAddrRes check function being called even when the address type was set to public, and so the check is irrelevant and returns the admittedly correct response given the function name, but this causes advertising not to happen. The previous thread's workaround was therefore to bypass this check by returning TRUE if the addrtype is public.

    Best regards,
    Aslak