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]

dr9 said:

Might be something with the older iOS.  I'm updating that phone now, too.

Updated to iOS 14 - no change in behavior observed.

Sniffer traces are attached. 

The trace titled "...sniffer_connects" represents what happens when the peripheral wakes up while the central is awake.  The trace titled "...sniffer_doesn't_connect" represents what happens when the peripheral wakes up while the central is asleep.  

3681.20200923 - sniffer_connects.pcapng

6327.20200923 - sniffer_doesnt_connect.pcapng

[dr9]

adding a second set of traces in case you want to see multiple samples.20200923 - sniffer_connects - 2.pcapng20200923 - sniffer_doesnt_connect - 2.pcapng

[Kenneth]

Looks like all logs connect here, and all logs also indicate the link is encrypted. So I guess this point to a different reason than it's not connecting?

Can you try to comment out pm_handler_secure_on_connection() in your application?

[dr9]

Same behavior with pm_handler_secure_on_connection() commented out in peer_manager_handler.c

Sniffer logs attached.

20200924 - sniffer_doesnt_connect.pcapng

20200924 - sniffer_connects.pcapng

I'm not sure if it means anything, but in the log where the connection isn't established, the PHY shifts from 1M to 2M at line 42.  On the log showing a successful connection, it stays in 1M for the duration. 

[Kenneth]

Doesn't make much sense, sounds like an issue on phone side. But maybe you can change from BLE_GAP_PHY_AUTO to BLE_GAP_PHY_1MBPS in ble_evt_handler() to see if there is any difference:

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_1MBPS, // BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_1MBPS, // BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

Unfortunately the sniffer log is encrypted, so difficult to know exactly what is happening, this means we need the LTK to decrypt the data. 

To output the LTK the easiest may be to call pm_peer_data_bonding_load() to get the LTK, this can for instance be done after  PM_EVT_PEER_DATA_UPDATE_SUCCEEDED or PM_EVT_CONN_SEC_SUCCEEDED event in pm_evt_handler() in main.c.

                pm_peer_data_bonding_t peer_bonding_data;

                pm_peer_data_bonding_load(m_peer_id, peer_bonding_data);

                //16byte LTK in peer_bonding_data.own_ltk.enc_info.ltk;

I believe (hope) that the LTK can be inserted in wireshark the same way as legacy pairing with OOB:

https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/action_paired.html

I am not sure what is MSB and LSB in this case, so you may need to try both orders of the 16bytes LTK.

[dr9]

Yes - I agree.  I'm just surprised that the issue doesn't present itself with other chips/softdevices. 

Tried forcing 1MBPS in the ble_evt_handler() but observed no difference.  Will be trying per your edits next.

[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