Invalid MIC in mdot when the conduit is reset. Manual mode and Class C

[Sergio Valiente]

Hello,
I’m working in manual join mode and class C.
I had asimilary problem in the conduit but it was resolved sending:
https://192.168.2.1/api/loraNetwork?method=PUT&data={“lora”:{“enableStrictCounterValidation”:false}}&apply=now

But now, I have the problem if the conduit power off, and the mdot is on.
when the conduit power up, I send a packet to the mdot from the conduit but the mdot trace shows:

[TRACE] Check downlink counter rollover 00020008
[WARNING] Invalid MIC Addr: 00000001 FCnt: 00000008

the packets from the mdot to de conduit are received without problems.
if I reset the mdot all go well.
have I to disable some check in the mdot too?
thanks

[Jason Reiss]

Same issue as Conduit. Need to reset the downlink counter on the dot.

AT+DLC=0

Reusing/resetting counters is not best practice. OTA join is suggested.

[Sergio Valiente]

Hi Jason,
Is this not a good practice for safety or for other reasons?
Thanks

[Jason Reiss]

Security reasons. Reuse of counters gives an attack surface for attempting to gain the session keys by analysis of intercepted packets.

[Sergio Valiente]

OK. I have a problem to reset the downlink counter. I can not detect this error in my program. In the example (dot_util.h). the menssage “MIC_FAIL” is not written. I only see the internal debug messages:

[TRACE] Check rollover of downlink counter 00020008
[WARNING] Not valid MIC Addr: 00000001 FCnt: 00000008

But I do not know how to detect them
Why not detect the error event MIC_FAIL in the Multitech example dot_util.h?:

public:
RadioEvent() {}

virtual ~RadioEvent() {}
char rx_string[128];
int i;
/*!
* MAC layer event callback prototype.
*
* \param [IN] flags Bit field indicating the MAC events occurred
* \param [IN] info Details about MAC events occurred
*/
virtual void MacEvent(LoRaMacEventFlags* flags, LoRaMacEventInfo* info) {

if (mts::MTSLog::getLogLevel() == mts::MTSLog::TRACE_LEVEL) {
std::string msg = “OK”;
switch (info->Status) {
case LORAMAC_EVENT_INFO_STATUS_ERROR:
msg = “ERROR”;
break;
case LORAMAC_EVENT_INFO_STATUS_TX_TIMEOUT:
msg = “TX_TIMEOUT”;
break;
case LORAMAC_EVENT_INFO_STATUS_RX_TIMEOUT:
msg = “RX_TIMEOUT”;
break;
case LORAMAC_EVENT_INFO_STATUS_RX_ERROR:
msg = “RX_ERROR”;
break;
case LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL:
msg = “JOIN_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_DOWNLINK_FAIL:
msg = “DOWNLINK_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_ADDRESS_FAIL:
msg = “ADDRESS_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_MIC_FAIL:
msg = “MIC_FAIL”;
break;
default:
break;
}
logTrace(“Event: %s”, msg.c_str());

logTrace(“Flags Tx: %d Rx: %d RxData: %d RxSlot: %d LinkCheck: %d JoinAccept: %d”,
flags->Bits.Tx, flags->Bits.Rx, flags->Bits.RxData, flags->Bits.RxSlot, flags->Bits.LinkCheck, flags->Bits.JoinAccept);
logTrace(“Info: Status: %d ACK: %d Retries: %d TxDR: %d RxPort: %d RxSize: %d RSSI: %d SNR: %d Energy: %d Margin: %d Gateways: %d”,
info->Status, info->TxAckReceived, info->TxNbRetries, info->TxDatarate, info->RxPort, info->RxBufferSize,
info->RxRssi, info->RxSnr, info->Energy, info->DemodMargin, info->NbGateways);
}
….

[Jason Reiss]

The RxDone event should occur on any packet received. Valid or invalid.

The packet has not been processed so the counter is in the payload buffer.

You could compare the devaddr and counter in the received packet with the current counter.

[Author]

Posts