bad_mic Frame Counter is a 16 bit binary in message but a 32bit counter in end node

[MPC]

Hi,

There is a flaw in the LoRaWAN spec which causes issues when the frame counter overflows from 0xffff to 0x0000.

The frame counter in the message structure is 16 bit but the actual counter in the end-node loraWAN stack is 32 bit.

The 32 bit frame counter is used to encrypt the payload message but since the message frame counter is only 16bits the server has no way of knowing what the upper 16 bits should be.

The spec gets round this by a very vague statement lines 531 to 533:

Note: Since the FCnt field carries only the least-significant 16 bits of the 32-bits frame counter, the server must infer the 16 most-significant bits of the frame counter from the observation of the traffic.

I think the LoRaWAN server must ignore the overflow of the frame counter as with our sensors the overflow causes continuous bad_mic errors.

Is it possible for the LoRaWAN server to identify the overflow and keep a tally of the upper 16 bits?

MPC.

[MPC]

Hey my error, again did not realise there was a setting in the Profiles. If you change the FCnt Check to strict 32-bit this copes with the 16bit frame count overflow.

MPC