1 Reply
      Latest reply on Nov 8, 2019 2:52 AM by kimalive
      kimalive Level 1 Level 1 (0 points)

        Some iPhone11's under certain conditions are sending two consecutive BLE Link Layer requests with a Control Opcode of 0xFF, which is in the 'reserved' range of BT sig specified codes. This appears to be a violation of the BT spec and is causing our peripheral device running a Nordic nRF52832 module and SoftDevice to disconnect with a disconnect reason of 0x2A (BLE_HCI_DIFFERENT_TRANSACTION_COLLISION).

         

        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. It causes our custom BLE device to disconnect but also other example peripheral apps running on the Nordic nRF52 dev board.

         

        Steps to reproduce the issue:

        1. iPhone8 with BT enabled, locked with screen off. Wait for about 1 minute.
        2. From the iPhone11, run the Nordic nRFConnect app and connect to a BLE peripheral device using the nRF52832 module.
        3. Wake up the iPhone8 (No need to unlock, just waking up so the screen turns on is enough)

         

        Result:

        The peripheral device will immediately disconnect and the nRFConnect app on the iPhone11 is disconnected after 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 Nordic BT stack always returns a disconnect reason BLE_HCI_STATUS_CODE = 0x2A

         

        I don't know how wide-spread this issue is and 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, iPhone11 Max and Pro.

         

        Tested BLE Peripheral.

        • ble_app_blinky example app and our custom BLE device
        • 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 1 3.2
        • iPad Air, A1474, iOS 12.4.1
        • iPad Air2, A1566, iOS13.1
        • Samsung S8

         

        The only combination out of these devices that can produce the issue are:

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

         

        The issue is reproducible 100% of the time.

        The issue never occurs while the iPhone8 A1863 is locked

        The issue never occurs with the iPhone11 (A2221 model), 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.

         

        BT Sniffer log from iPhone11, nRFConnect, Nordic blinky BLE peripheral app.

        0xFF LL requests from iPhone11, followed by LL_UNKNOWN_RSP response and disconnect from the peripheral device which then starts advertising again.

        https://www.dropbox.com/s/4m1bmpe9liiz1v1/iPhone11-Nordic-justbeforedisconnect.png?dl=1

         

         

        When connected to a different BLE peripheral device that has a different BT stack that is not using the Nordic BLE module, the iPhone11 is still sending the two BLE Link Layer requests, but this device replies with two LL_UNKOWN_RSP responses and does not disconnect.

        https://www.dropbox.com/s/2gf1s5g81tovbzn/iPhone11-itens-stays-connected.png?dl=1

         

         

        • Has anyone else run into this issue or noticed random disconnects when an iPhone11 is connected to a BLE device?
        • 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?