iPhone won't connect: Unknown Opcode [v14.2 + S132 v5.1.0]

[SRA]

Just had a contractor update our project (simple device is peripheral and server for some GATT data) from SDK v12.x with S132 4.0.5 to v14.2 with S132 5.1.0.

All works great on old SDK and old S132. Now, on connect, before service discovery, the sniffer reports an UNKNOWN OPCODE, the connection stalls for 14-15 seconds, then device terminates connection.

Samsung Galaxy S8 : works

Apple iPhone 6 : works

Apple iPhone 8 : device returns unknown opcode, connection halts

This is the list of activity before the connection halts on iPhone8:

37	1.575603	72:4a:da:4b:cc:54	dc:60:ad:84:5a:5e	LE LL	60	CONNECT_REQ
38	1.579929	Master_0x506573d0	Slave_0x506573d0	LE LL	32	Control Opcode: LL_VERSION_IND
39	1.583712	Slave_0x506573d0	Master_0x506573d0	LE LL	26	Empty PDU
40	1.596014	Master_0x506573d0	Slave_0x506573d0	LE LL	26	Empty PDU
41	1.600075	Slave_0x506573d0	Master_0x506573d0	LE LL	32	Control Opcode: LL_VERSION_IND
42	1.628776	Master_0x506573d0	Slave_0x506573d0	LE LL	35	Control Opcode: LL_FEATURE_REQ
43	1.645059	Slave_0x506573d0	Master_0x506573d0	LE LL	26	Empty PDU
44	1.657012	Master_0x506573d0	Slave_0x506573d0	LE LL	26	Empty PDU
45	1.664512	Slave_0x506573d0	Master_0x506573d0	LE LL	35	Control Opcode: LL_FEATURE_RSP
46	1.686342	Master_0x506573d0	Slave_0x506573d0	LE LL	35	Control Opcode: LL_FEATURE_REQ
47	1.690928	Slave_0x506573d0	Master_0x506573d0	LE LL	26	Empty PDU
48	1.717988	Master_0x506573d0	Slave_0x506573d0	LE LL	26	Empty PDU
49	1.733796	Slave_0x506573d0	Master_0x506573d0	LE LL	35	Control Opcode: LL_FEATURE_RSP
50	1.746914	Master_0x506573d0	Slave_0x506573d0	LE LL	29	Control Opcode: Unknown
51	1.754934	Slave_0x506573d0	Master_0x506573d0	LE LL	26	Empty PDU
... 14-15 seconds of this
xx	xx.xx 		Master_0x50654595	Slave_0x50654595	LE LL	28	Control Opcode: LL_TERMINATE_IND

Here is a pull down of that "UNKNOWN OPCODE" from Wireshark/Sniffer that coincidentally makes the iphone drop the connection:

Bluetooth Low Energy Link Layer
Access Address: 0x506573d0
[Master Address: 72:4a:da:4b:cc:54 (72:4a:da:4b:cc:54)]
[Slave Address: dc:60:ad:84:5a:5e (dc:60:ad:84:5a:5e)]
Data Header: 0x0303
    .... ..11 = LLID: Control PDU (0x3)
    .... .0.. = Next Expected Sequence Number: 0
    .... 0... = Sequence Number: 0 [OK]
    ...0 .... = More Data: False
    000. .... = RFU: 0
    ...0 0011 = Length: 3
    000. .... = RFU: 0
Control Opcode: Unknown (0x16)
Unknown data
CRC: 0x37ade1

This is line 49, LL_FEATURE_RSP on an iphone8 (doesn't work):

Control Opcode: LL_FEATURE_RSP (0x09)
Feature Set: 0x0000000000004125
    .... ...1 = LE Encryption: True
    .... ..0. = Connection Parameters Request Procedure: False
    .... .1.. = Extended Reject Indication: True
    .... 0... = Slave Initiated Features Exchange: False
    ...0 .... = LE Ping: False
    ..1. .... = LE Data Packet Length Extension: True
    .0.. .... = LL Privacy: False
    0... .... = Extended Scanner Filter Policies: False
    Reserved: 41000000000000
CRC: 0x043ee5

This is the same line, LL_FEATURE_RSP on an iphone6 (does work):

Feature Set: 0x0000000000004101
.... ...1 = LE Encryption: True
.... ..0. = Connection Parameters Request Procedure: False
.... .0.. = Extended Reject Indication: False
.... 0... = Slave Initiated Features Exchange: False
...0 .... = LE Ping: False
..0. .... = LE Data Packet Length Extension: False
.0.. .... = LL Privacy: False
0... .... = Extended Scanner Filter Policies: False
    Reserved: 41000000000000
CRC: 0x613926

Does anyone have a clue here? I don't know how to find the BLE Opcodes right away, not sure if 0x16 is really unknown or not. I haven't seen a lot of iPhone8 mentions with S132 v5.1.0.

Attaching full capture.

[MartinBL]

Hi,

The opcode probably shows up as "Unknown" because Wireshark doesn't support the new BLE 5.0 opcodes yet. If you look at your packet in question you can see that it is a link layer opcode. If you go further and look up the LL opcode 0x16 in the Bluetooth Core Specification you will see that this is the LL_PHY_REQ opcode. Here is a quote from the Spec (BLUETOOTH SPECIFICATION Version 5.0 | Vol 6, Part B, 5.1.10 PHY Update Procedure):

The PHY Update Procedure, when supported, is used to change the transmit or receive PHYs, or both. The procedure can be initiated either on a request by the Host or autonomously by the Link Layer. Either the master or the slave may initiate this procedure at any time after entering the Connection State. Link Layer PHY preferences may change during a connection or between connections and, therefore, they should not be cached by the peer device.

When this procedure is initiated by the master, it sends an LL_PHY_REQ PDU. The slave responds with an LL_PHY_RSP PDU....

In your log it seems like your iPhone 8 sends an LL_PHY_REQ wanting to update the physical layer used in the link. However, you can also see that the nRF52 never responds. Hence, I'm wondering whether your contractor forgot to implement the handling of phy requests in the project. Please refer to the Migration Document for S132 v5.0.0 (no such document exist for v5.1.0) to see how this should be implemented.

The quote from the spec mentions that a phy request might be sent either on a request from the Host or autonomously by the Link Layer, so I suppose your Samsung S8 and iPhone 6 doesn't send any phy requests autonomously and hence there's no problem.

[SRA]

Martin, the migration document was helpful thanks again.