CC2642R: Unable to connect to device configured as peripheral after bonding

I'm actually not seeing my wireshark logs upload properly, is there some trick to attaching files? 

Have made one drive links to get around this: 

bond-then-connect-fail:

https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EY8hgVpT2U5ApgeNBGHLujsBDd2NFduyau3mrsdFNDJm0w?e=jfUzbq

anna-to-anna:

https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EV9I1zqE_flLv0NCb1GvATgBQZcF5h53Fuy2ySLcq3vFKg?e=LagVha 

Hi Ben,

Thanks for the post.

I have notified the BLE team for further comment.

Thanks,
Toby

Hi Ben,

For information, I cannot decode the sniffer log as it requires a plugin we cannot get access to.

In order to narrow down the problem, I would recommend to check whether changing the address mode used by the CC2642R could help. To do so, in the CCS project you can use SysConfig to modify the address mode used by the device. Here, I would recommend to use "Public Address" for a first test.

Keep us updated,

Best regards,

Hi Clément,

We've already tried all the ADDRMODE settings, saw the same issue on RPA with public ID. We use public address by default, 

If it helps, here's an expanded version of the one packet that's just being ignored by the CC2642R. 

If that's not enough information, what packet sniffer would you recommend that you guys would be 

Hi,

Thank you for the details provided. Would you mind to provide the details on the CONNECT_IND packet (which seems the first one not answered by the device)?
If possible, I would like to see the difference between a valid CONNECT_IND packet and the failing one.

You can use https://www.ti.com/tool/PACKET-SNIFFER/ as a sniffer for example.

One more avenue to explore is whether the CC2642R has enabled some address filtering (allow or deny list - called before white and black lists). In that case it could explain why the device does not answer the connection request.

Best regards,

Here's some CONNECT_IND messages in case its useful

CONNECT_IND that precedes a failure. 

CONNECT_IND that occurs when bonding:

CONNECT_IND that occurs on a normal connection where bonding has not been attempted:

I'll try to get that sniffer set up, but hopefully this works for now. I'll also take a look to see if address filtering was implemented. I would assume not, since connecting to the CC2642R works just fine as long as we haven't bonded. 

Hi,

Thank you for the elements provided.

I have mentioned is that uses always the public address of the CC2642R to establish the connection (see RxAdd). This is not correct in case the peripheral (CC2642R) enables privacy. It is apparently something that has been fixed by the other vendor: https://github.com/zephyrproject-rtos/zephyr/pull/6417
As I cannot access the details on the firmware used by your device, may I kindly ask you to verify if this fixed has been applied to your software?

Best regards,

I don't think that fix would have been applied, the firmware is using an older version of the Nordic Soft Device. If we think that might be the case I can double check however. 

I checked, our privacy setting, it looks like we have ADDRMODE_PUBLIC set and my understanding was that to enable privacy we'd need to set our address mode to ADDRMODE_RP_WITH_PUBLIC_ID to have privacy enabled according to https://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr.html?highlight=gap#null. So I'm guessing there might be something else going on. 

Hi,

Before going any further in the debugging, please make sure to use the latest software versions available for all the devices involved. Like you I believe something else is going on and I want to make sure we are not trying to fix something that is already fixed.

Best regards,

Hi Clement, yes we've been ale to replicate this issue using the Simple Peripheral example from the latest 6.40 SDK. However our custom application was started a while ago on the 2.40 SDK. 

Also, we're kind of more just trying to get info at this point rather than a fix. There's probably multiple ways we can approach this to get our product going. What we really want from you guys is just confirmation of whether the SDK should be responding to the messages we showed are being ignored in those wireshark logs. 

Hi Ben, 

I understand. 
At the moment, I cannot say for sure if the device should or should not answer here. As I mentioned there are a few elements that do not seem right to me, and, again, I would recommend to address them first. 

In case you are interested to consider other approaches - or rather approaches offering new data points to understand the issue - I would recommend attempting bonding with a different central device. For example, you could try to use a smartphone or a TI device (CC2640R2 or CC2642R) as central. The goal would be then to collect Bluetooth traces and compare to the ones originally collected. 

I hope this will help, 

Best regards, 

Hi Clement, 

We did try out a smart phone as a central and it worked fine. It was able to connect after bonding. However it did not send those messages that are being ignored by the CC2642R. 

I'm a little unsure of how to force a different central to send those same messages that are being ignored as a point of comparison. Would be good to get some suggestions for testing. I was hoping the wireshark logs would be enough to determine if the CC2642R is misbehaving or not. 

Also just an FYI someone else will likely be taking over this issue soon from our end. 

Hi,

Thank you for the heads up.

If I may, I doubt a phone or any other central may skip the emission of the CONN_IND packet. If it was not clear, the packet ignored is the CONN_IND, all the packets ignored afterwards (ATT Requests) are only a consequence of this first packet being ignored.

Best regards,

Sorry I guess I worded it weird, the phone doesn't skip the CONN_IND packet, what it does skip is the Central Address Resolution request messages.

I'm thinking it might make sense to try collecting sniffer logs in BTool at this point, if you guys don't have the wireshark plugin installed so you can take a more detailed look. I think the wireshark plugin presents the data well, but it's obviously hard to communicate over text and screenshots.