This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BLE master transmitting "LLCP Feature Response," slave disconnecting due to MIC failure (0x3D)

We are seeing unusual/unexpected disconnects between a CC256x BLE Master (operating in dual mode, with BT classic to an Android tablet) and slave. The scenario is:

1)      The Master connects to the slave, and establishes link layer encryption.

2)      After exchanging BLE data at about 4-5 KB/s for several seconds, the connection is lost.

a.       Just prior to the loss, the Master transmits LLCP Feature Response

                                                               i.      We don’t know why the CC256x is transmitting this – the trace shows no corresponding request from the slave

                                                             ii.      In this instance, the Feature Response has a valid payload (See Ellisys Trace #1 below)

3)      The Master attempts multiple times to reconnect, but reconnection fails.

a.       The Connection is successful.

b.       Connection parameter update is successful.

c.       The master issues “Encryption Start” to the slave (See Ellisys Trace #2 below)

                                                               i.      There is no response from the slave, but the Master now periodically transmits “LLCP Feature Response”. We suspect this is not supposed to happen.

                                                             ii.      However, the response PDU is now invalid – the payload length has been truncated from 12 bytes (valid) to 5.

                                                           iii.      Debug info on the slave side indicates that the slave terminated the connection due to a MIC failure (0x3D). That shouldn’t happen before encryption is established.

d.       Then the Master drops the connection due to a Supervisor Timeout

e.       Steps a-d repeat indefinitely. This scenario leaves the Master unable to reconnect.

4)      In all loss-of-connections above, the slave BLE stack reports the reason for the disconnect as 0x3D “Connection Terminated Due to MIC Failure”. We don’t see how that fits with the scenario in 3c above.

We first saw this rather frequently after enabling link layer encryption when the Master CC256x was configured with the TI BTS version 1.3 script. After updating to the 1.5 (current) BTS script, we saw about a 70% reduction in the occurrence of this scenario.

Given that the version of the BTS script makes a difference, and the traces show the master generating LL messages that are unexpected and appear to be incorrectly formatted, we don't see this pointing to the TI BT stack or the application FW.

Ellisys Trace #1:


 

Ellisys Trace #2: