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.

CC2642R: MIC failure on ATT Write Request after rejected encryption procedure

Part Number: CC2642R

Host (Android 6 STB) is starting encryption procedure which is getting rejected by our device since bonding got deleted on peripheral -> Pin or Key missing.
So far so good - everything as expected, but a service on host is now trying to enable the Client Characteristic Configurations for a Characteristic he still knows of (Handle 40 in this case) which is immediately generating a "MIC Failure" on peripheral side - connection drops on periphal and since it was a MIC Failure peripheral is also able to start advertisment again, host on the other side is still stuck with the supervisionTimeout since peripheral did not send a connection termination packet to host (as expected since it's a MIC Failure....).

The question here is - why is CC2642R generating a MIC Failure even tho the packet was correctly transmitted (ellisys airtraces attached) with a valid CRC & MIC?
Could it be that the stack is still in the encryption procedure even tho it has been completed (Core Spec 5.1, Vol 6, Part B, 5.1.3.1 Encryption Start procedure) by reception of LL_REJECT_EXT_IND PDU by the master?

SDK: SimpleLink™ CC13x2_26x2 SDK 3.10.00.53 using IAR Embedded Workbench: EWARM-8.32.4

thanks & best regards,
daniel

cc2642r1_mic-failure-after-enc-procedure_20191024.zip

  • Hi Daniel,

    This is what I see on the log you posted:

    1. The devices connect

    2. LL feature and version exchanges

    3. Master sends encryption request, the encryption is rejected by the slave with reason PIN or Key missing.

    4. (Connection parameter update)

    5. Master requests encryption, again the encryption is rejected by the slave with reason PIN or Key missing.

    6. (Connection update, multiple empty packets)

    7. Write request from the master

    8. The slave stops responding to connection events. (I assume it displays MIC failure?)

    I would expect the slave to respond with an ATT error response: "insufficient encryption". 

    I will try to reproduce here and get back to you. 

  • hi Marie,

    agree with all 8 steps and yes it displays MIC Failure / disconnect reason 0x3D - question is why/how.
    not sure about the ATT error response - writing should also be possible without encryption, especially if permission for attribute is writeable/0x02?

    best regards,
    daniel

  • Hi Daniel,

    I just tested with simple peripheral and using Host Test + BTool as the master. When I delete the bond on simple peripheral, then reconnect and try reading characteristic 5 I get the ATT error response with reason Insufficient Authentication as expected. (I tested with SimpleLink CC13x2/CC26x2 SDK 3.30.)

    Does your CCFG have the GATT_PERMIT_AUTHEN_WRITE, GATT_PERMIT_AUTHOR_WRITE or GATT_PERMIT_ENCRYPT_WRITE permission?

    Did you test with 3.30 SDK?

  • hi Marie,

    permissions for CCFG are set to "GATT_PERMIT_READ | GATT_PERMIT_WRITE" on my side.
    I've just re-checked the release notes / changelogs from 3.10 till 3.30 ... it seems that in 3.20 this issue might have been fixed (BLE_AGAMA-503: simple_peripheral re-connection after bond cleared terminate due to MIC error) - since we're upgrading to 3.30 in the next 1-2 weeks I'll retest this on our side again once updated and report back if fixed or not!

    thanks & best regards,
    daniel