MIC Check Failed

[Antonio Muñoz]

Hello
I’m having problems sending data to the conduit.
This message appears in the log and the data does not go up.

Does anyone know why this happens ??
How can I solve that ??

Thank you

11:50:49:292|TRACE| TX-ACK|127.0.0.1:45249 4 bytes 01fb6301
11:50:49:293|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PUSH-DATA|127.0.0.1:45249
11:50:49:294|INFO| GW:00-80-00-00-00-00-aa-85|FRAME-RX|Parsing 1 packets
11:50:49:296|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-RX|DATA: 404f1e0f01800c0096e4d50cf78b
11:50:49:296|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-RX|FREQ: 864.900000 MHz DR0 RSSI: -87 dB SNR: 82 cB
11:50:49:297|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-RX|TYPE: Unconfirmed Up
11:50:49:297|DEBUG| GW:00-80-00-00-00-00-aa-85|PACKET-RX|ADDR: 01:0f:1e:4f FCnt:000c
11:50:49:298|WARNING| Performing lazy check of counter, replay attack possible
11:50:49:298|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:298|TRACE| PMIC: d50cf78b CMIC: 63e6ea01
11:50:49:299|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0000000c
11:50:49:299|TRACE| 4557838 ms since last packet
11:50:49:300|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:300|TRACE| PMIC: d50cf78b CMIC: 63e6ea01
11:50:49:301|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0000000c
11:50:49:301|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:306|TRACE| PMIC: d50cf78b CMIC: 154f752c
11:50:49:306|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0001000c
11:50:49:307|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:308|TRACE| PMIC: d50cf78b CMIC: 5a3c7d4a
11:50:49:308|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0002000c
11:50:49:308|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:309|TRACE| PMIC: d50cf78b CMIC: a61c2875
11:50:49:309|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0003000c
11:50:49:310|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:311|TRACE| PMIC: d50cf78b CMIC: c72276b2
11:50:49:311|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0004000c
11:50:49:311|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:312|TRACE| PMIC: d50cf78b CMIC: f319e106
11:50:49:312|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0005000c
11:50:49:313|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:313|TRACE| PMIC: d50cf78b CMIC: 491b6662
11:50:49:313|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0006000c
11:50:49:314|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:314|TRACE| PMIC: d50cf78b CMIC: 5c535ec5
11:50:49:315|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0007000c
11:50:49:315|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:316|TRACE| PMIC: d50cf78b CMIC: 522bf4db
11:50:49:316|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0008000c
11:50:49:317|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:317|TRACE| PMIC: d50cf78b CMIC: d5c80c2b
11:50:49:318|WARNING| ED:01-23-a3-0b-00-1e-a5-a0|CHECK-PKT|MIC Check Failed 0x0009000c
11:50:49:318|TRACE| AUTH KEY: 68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c
11:50:49:318|TRACE| PMIC: d50cf78b CMIC: d1ce9f78

[Jason Reiss]

How is the end-device joined to the Conduit? OTAA or ABP

Does this key match the end-device Network Session Key?
68.44.bf.f1.51.c9.f5.0c.bd.5f.1f.d8.31.90.0f.8c

Apparently there is a record of DevAddr 01:0f:1e:4f associated with DevEUI 01-23-a3-0b-00-1e-a5-a0 on Conduit.

Have you upgraded to AEP 1.4.16, the session information is available through the GUI. Keys and counter values. Check that the settings are matching the end-device.

[Antonio Muñoz]

Hi
The device is OTAA joined.
Normally paketes are received well.
But when this happens, the only solution is to make another Join OTAA. But the node does not know it.
I have version 1.4.16.
I would like to know what is the reason that this problem occurs and how to solve it.

Thanks again.

[Jason Reiss]

The reason for MIC fails is a mismatch in Session Keys or Frame Counters.

What end-device is being used?
How many packets are received OK before the issue starts?

Do you have reason to have the strict counter disabled?
11:50:49:298|WARNING| Performing lazy check of counter, replay attack possible

Usually this is used for end-devices that cannot save counter state.
Perhaps try to re-enable this if possible.
Otherwise if the device does lose the counter perhaps the key is lost too and a join is necessary to regain connectivity.

[Antonio Muñoz]

Hi.
The device is RN2483.
You can receive many packages before this happens. It is sporadic. I have the counter disabled (“enableStrictCounterValidation”: false).
because the packets are sent without confirmation, one or more can be lost and the counters do not match. This is a security measure that in my opinion gives more problems than it solves.
If I have enableStrictCounterValidation = false, why does not it pass the packets?
thanks

[Jason Reiss]

The packet does not pass because the MIC cannot be validated. Either the end-device has lost the session keys and the counter, or the network server has lost the session. It should be easy to look at the session keys on the Conduit right after the device joins and see if they have changed when you see the issue.

There is no problem of missed packets in either case. The counter can always be moved forward, up to 16384 missed packets.
The issue is when the counter decreases at the end-device or it is reset to zero, as the case with some devices on power cycle.

Is the end-device counter being reset to 0 at any time?
This is not expected behavior of an OTA end-device. The counter should only increase.

Have you checked that the RN2463 has been updated to the latest firmware?

[Antonio Muñoz]

I’m going to study the information you give me. I have to analyze what happened on the device.
Thanks again.

[Author]

Posts