nRF52810 S112 background reconnect issue

[dr9]

Hi,

I'm working through a number of the PCA10040e examples (SDK16 | S112 | nRF52810 - mouse and keyboard to be specific) and have noticed some irregular behavior when waking the peripheral from sleep.  After bonding, if you put the peripheral to sleep, and let the central go to sleep as well (screen locked/off, no audio playing, etc.) and then wake the peripheral, the connection is not reestablished.  To restore the connection, you have to restart the peripheral with the central awake (i.e. being moved, screen on, audio playing, etc.)  However, if the central is "awake" when the peripheral is woken up, the connection is restored as expected.

I tried this with a nRF52832 (same examples in PCA10040 with S132) and the issue does not present itself.  The connection is able to be reestablished with the central sleeping.  Is this something to do with the Soft Device?  I plan on running a set of sniffer traces this afternoon and will post the results.

Thanks

p.s. central is an iOS device at this time.

[dr9]

Not sure if it helps, but I did find that if I make a call to advertising_start() sometime after the peripheral is running, with the central still sleeping, it does connect. 

[Kenneth]

You can find in chapter 35 in the Apple Bluetooth guidelines some recommendations to parameters that should be used: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

For instance I believe the advertising_start() may start by doing directed advertisement, this is not recommended by apple, see chapter 35.3. So you may need to init advertisement module without directed advertisement enabled.

Apple also have some suggestions for advertisement intervals.

[dr9]

I have a hex word printing from a debug terminal that I can enter into the passkey field.  Is this what you are looking for?

[Kenneth]

The LTK should be:
uint8_t   ltk[BLE_GAP_SEC_KEY_LEN];   /**< Long Term Key. */

You may set a breakpoint in your project just to read out the LTK, since it doesn't change you only need to read it once and it will be valid until you re-bond. After reading out the LTK you can then disconnect the debugger and run the application as normal with the nRF Sniffer.

[dr9]

Finally got this working.  Lines 11659-12577 represent a failed reconnect effort.  Lines 12642-13580 represent a successful one.  The firs obvious difference is that an MTU exchange is not happening.  Beyond that, I'm unsure where to look for clues as to what is not working properly.20200925 - full capture.pcapng

[Kenneth]

Please comment out pm_handler_secure_on_connection(), since that break with the apple guidelines chapter 35.10.

I am not sure if I understand what is actually failing, because both instances show that the peers do connect, they encrypt, and for instance the battery level is notified from the peripheral to the central every 2 seconds. So I guess the question is, what is not working here? What happens if you for instance press a key?

There is nothing in the logs that indicate an issue with the peripheral, so if the phone behave differently then I suggest contacting apple on this issue.

The logs do show that the phone for one of the connections do also execute a write to the CCCD's, however the application on the peripheral do not require this, as the CCCD's are already stored from previous connection and thereby restored on connection (which is why the battery level notification works in both cases).

Best regards,
Kenneth

[dr9]

Kenneth said:

 pm_handler_secure_on_connection()

was commented out in peer_manager_handler.c for the build associated with that trace.

When I wake the central after waking the peripheral, the peripheral shows as "not connected" in the central's Bluetooth devices list.  As expected, pressing a key yields no response from the central. 

If I compile and build this to a nRF52832 using S112, the same behavior is observed.  If I build with S132, the peripheral reconnects in the background without an issue. By elimination, it looks like the differences in S112 and S132 somehow contribute to the difference in behavior.   Thoughts?

And yes, I'll reach out to Apple, too.

[Kenneth]

dr9 said:

was commented out in peer_manager_handler.c for the build associated with that trace.

Are you sure? Because the trace do show SMP request on both 12646 and 11661, then something else must be calling the security request in your code.

 

dr9 said:

As expected, pressing a key yields no response from the central. 

But neither working or failing log show any key presses (that should trigger a notification for the key press), only battery level notification is shown:

Edit: Something is not as it should be here: the central is writing multiple write requests with the value of 00 to the same handle (0x001e). This isn't really an issue and is allowed to do, but seems unnecessary. What iPhone and ios version was 20200925 - full capture.pcapng?

[dr9]

Kenneth said:

But neither working or failing log show any key presses (that should trigger a notification for the key press), only battery level notification is shown:

EDIT: peripheral on, not connected to central:

peripheral on, connected to central:

-----end_edit

Yes - just did a clean build and capture:

Kenneth said:

Are you sure? Because the trace do show SMP request on both 12646 and 11661, then something else must be calling the security request in your code.

edit: I only found pm_handler_secure_on_connection() being called in peer_manager_handler.c

Kenneth said:

What iPhone and ios version was

iPhone 8, iOS 14.0.

[Kenneth]

Can you try to trace back in your code to where sd_ble_gap_authenticate() may be called? I assume setting a breakpoint may help, since it shouldn't be called here.

Best regards,
Kenneth

[dr9]

Its being called in security_dispatcher.c 

snapshot of the call stack:

[Kenneth]

Seems this can be called from two places, please comment out pm_handler_on_pm_evt() in pm_evt_handler().

Best regards,
Kenneth