Single lost BTLE packet causes entire connection to close

[silbe]

We're having a problem using GATT with a BTLE peripheral running Zephyr on nRF52840 (most likely not hardware specific, see below). From time to time when performing a GATT read the response doesn't arrive on the master side and the connection gets closed after 30s.

Using a BTLE sniffer we can see that the master (PC) sends out the Read Request and that the slave (peripheral) sends a Read Response. Then for about 30s only empty PDUs get exchanged and after that the connection gets terminated by the master. The master controller never forwards the Read Response to the software so it probably wasn't received correctly (interference).

Diving into the Bluetooth specification, it looks like this is pretty much by design. We use the fixed L2CAP channel for ATT over LE (CID 4, see Bluetooth Core Specification (BCS) v5.2 Vol 3 Part A section 2.1 Channel identifiers). This channel operates in Basic Mode (see BCS Vol 3 Part G section 5.2.2 LE channel requirements), providing no retransmission support (see BCS Vol 3 Part A section 2.4 Modes of operation and BCS Vol 3 Part A section 8 Procedures for flow control and retransmission). Instead, missing packets cause an ATT transaction to time out after 30s and no further packets may be sent on the existing ATT bearer (see BCS Vol 3 Part F section 3.3.3 Transaction). This means the L2CAP channel needs to be reconnected. For the LE fixed ATT channel, the entire physical layer BTLE connection needs to be reconnected (see BCS Vol 3 Part F section 3.2.11 ATT bearers).

Is our analysis correct? What can we do to fix this? It looks like Zephyr does not support L2CAP Retransmission Mode (as specified in BCS Vol 3 Part A 3.3 connection-oriented channel in retransmission/flow control/streaming modes). Is there any plan to implement this support?

[hermabe]

The ATT timeout is there by spec and is not something we can change. However, if you see the response packet in the sniffer it is odd that zephyr does not receive it. Do you have a sniffer trace you can share? Is the packet acked by the controller? If yes, it should be propagated to the host/upper layers.

[silbe]

Got clearance now for sharing the capture file. Where should I upload it? I cannot see a way to attach it to this discussion. Should I create a ticket and attach it there?

[hermabe]

If you believe this is a bug in the zephyr ble stack you should create an issue instead and attach the sniffer trace there along with any steps to reproduce it.