iPhone11 causing SD to disconnect with disconnected reason - BLE_HCI_DIFFERENT_TRANSACTION_COLLISION (0x2A)

[kbarnett]

I'm having an issue with some iPhone11's, where under certain conditions the iPhone11 is sending two consecutive Link Layer requests with a Control Opcode of 0xFF. The SoftDevice responds with LL_UNKNOWN_RSP and disconnects with BLE_HCI_DIFFERENT_TRANSACTION_COLLISION.

It looks like the iPhone is violating the BT spec by sending 2 of these LL requests without waiting for a response and the SD disconnects in this situation.

I see in the Nordic s132_nrf52_5.0.0 release notes, a change was added to allow overlapping LL requests 'for compatibility' reasons. However, it doesn't look like this includes overlapping 'duplicate' LL requests or unknown control procedures. The SoftDevice slave role now accepts overlapping peer-initiated Link Layer control procedures (DRGN-8623). The following LL control procedures can be executed in parallel with any other control procedure, except for themselves: LE Ping, Feature Exchange, Data Length Update, and Version Exchange. This is done for compatibility reasons. The SoftDevice now has improved control procedure performance in scenarios involving multiple links (DRGN-9001). 

Wouldn't it be a safer option for compatibility reasons to also not disconnect from multiple unknown LL requests and is there any way to configure the SD to allow this. I have reproduced and tested this issue with another BLE device that uses a different BT stack and module from TI and noticed that they just reply to each 0xFF LL request from the iPhone11 with an LL_UNKNOWN_RSP response and do not disconnect.

We are seeing this issue with some iPhone11's but not all iPhone11's and it appears to be dependent on other iPhones being in proximity, unlocked and with BT enabled. 

I have been able to reproduce the issue 100% of the time with the Nordic nRFConnect app running on the iPhone11, connected to the ble_app_blinky peripheral app running on the PCA10040 dev board, with the following steps:

Steps:

1. iPhone8 with BT enabled, locked with screen off. Wait for about 1 minute.
2. Run the ble_app_blinky peripheral example app from the nRF SDK.
3. From the iPhone11, run the nRFConnect app and connect to the Nordic Blinky peripheral.
4. Wake up the iPhone8 (No need to unlock, just waking up so the screen turns on is enough)

Result:

Blinky app will immediately disconnect and start advertising, and nRFConnect on the iPhone11 is disconnected from a timeout. This occurs every time with a specific pair of iPhones, provided the iPhone8 has had sufficient time in the locked/screen off state. The issue is always the same transaction collision from two 0xFF LL requests from the iPhone11 and the SD always returns a disconnect reason BLE_HCI_STATUS_CODE = 0x2A (BLE_HCI_DIFFERENT_TRANSACTION_COLLISION) in the ble event handler.

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context) {
ret_code_t err_code;
switch (p_ble_evt->header.evt_id) {
    case BLE_GAP_EVT_DISCONNECTED:
        NRF_LOG_INFO("DISCONNECTED. BLE_HCI_STATUS_CODE=%02X", p_ble_evt->evt.gap_evt.params.disconnected.reason);

...

I don't know how widespread this issue is because I only have 1 pair of iPhones that can reproduce this issue, although we have reports of random disconnects from some others with iPhone11's.

Tested FW.

• ble_app_blinky example app and our own custom peripheral app.
• nRF SDK 15.3.0 + SD s132_nrf52_6.1.1 and nRF52 SDK16.0.0 + SD s132_nrf52_7.0.1

Test Devices

• iPhone11, A2111, iOS 13.1.3 (Purchased in USA)
• iPhone11, A2221, iOS 13.1.3 (Purchased in Australia) 
• iPhone10, A1865, iOS 13.2
• iPhone 8, A1863, iOS 13.2
• iPhone7+, A1661, iOS  13.1.3
• iPhone6, A1549, iOS 12.4.2
• iPhone6S, iOS 13.2
• iPad Air, A1474, iOS 12.4.1
• iPad Air2, A1566, iOS13.1
• Samsung S8

The only combination of tested devices that reproduce the issue are:

• iPhone 11, A2111, MWLG2LL/A, iOS 13.1.3 (Connected device)  
• iPhone 8, A1863, MQ742LL/A, iOS 13.2 (device in proximity with BT enabled)

The issue never occurs while the iPhone8 A1863 is locked, and never occurs with the iPhone11 (A2221 model) or any of the other iPhone, only the iPhone11 (A2111 model).

If the iPhone8 is unlocked when the iPhone11 connects to a Nordic peripheral, the disconnect issue occurs randomly but typically after being connected for about 30secs.

I have tried disabling every option I could think of on the iPhone8, including all background apps, disabled WiFi, no SIM, removed all BT paired devices, etc.

BT Sniffer log from iPhone11, nRFConnect, blinky app.

0xFF LL requests from iPhone11, followed by LL_UNKNOWN_RSP response and disconnect from blinky app which then starts advertising again.

BT Sniffer log from iPhone11, nRFConnect connected to iTENs BLE device (Different BT stack - not using Nordic module).

two 0xFF LL requests from iPhone11, with two LL_UNKNOWN_RSP responses from BLE device. Does not disconnect.

BT Sniffer logs captured in Wireshark:

/cfs-file/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-db1fc52952974aa782451f5bf686edc1/BTLog_2D00_iPhone11_2D00_connected_2D00_to_2D00_blinky.pcapng

/cfs-file/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-db1fc52952974aa782451f5bf686edc1/BTLog_2D00_iPhone11_2D00_connected_2D00_to_2D00_iTENs.pcapng

- Has anyone else run into this issue or noticed random disconnects when connected to an iPhone11?

- Any ideas on why the iPhone11 is sending Link Layer requests with a Control Opcode of 0xFF, in the 'reserved' range of codes and triggered by an iPhone8 in proximity waking up?

[Einar Thorsrud]

Hi,

There was a severe issue with iPhone 11 where it ignored ATT packets in the first connection event. So if the nRF sent an ATT packet in the first connection event, this was asked by the iPhone 11, but ignored, leading to an ATT timeout 30 seconds later. This has been fixed in iOS 13.2 (the fix is that the iPhone does not ack the packet received in connection event 0, so that it is retransmitted in the next connection event, where it is handled properly). This issue first with most of your description, but not BLE_HCI_DIFFERENT_TRANSACTION_COLLISION. In this case, you will get a disconnect with reason BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION. Can you test upgrading to iOS 13.2 on the iPhone 11 to verify if this is it and that it is fixed?

The BLE_HCI_DIFFERENT_TRANSACTION_COLLISION is probably a different matter. This indicates (from spec): "The Different Transaction Collision error code indicates that an LMP transaction or LL Procedure was started that collides with an ongoing transaction". I have not seen reports of this with iPhone 11 earlier.

Since this is a bit odd, and we know there were several potentially relevant BLE issues in early iOS 13 versions, can you test again with iOS 13.2 on all devices?

[kbarnett]

Updating the iPhone11 to iOS13.2.2 has fixed the issue. I no longer see any 0xFF Link Layer requests from the iPhone11 or dropped connections.

[Einar Thorsrud]

Thank you for updating us.