Invalid MIC with Dragino LPS8N and MQTT Forwarder 4.1.3

[jka]

I installed today the MQTT Forwarder 4.1.3 on a Dragino LPS8N Gateway with FW lgw-5.4.1689641188, than with FW lgw-5.4.1668567157 and than with FW lgw-5.4.1693202489. Always the connection to Chirpstack runs fine but when I tried to send a join-request from different sensors, I got an invalid MIC error… Then I installed the the MQTT Forwarder 4.1.2 on FW lgw-5.4.1693202489 and my join-request works fine. I chanced definitely nothing on my configuration! I can’t imagine what the problem is…

[datnus]

You put in wrong keys for the nodes.

[jka]

No I don’t changed the keys, not in chirpstack and not in my nodes and it works with MQTT Forwarder 4.1.2.

[sp193]

But the error comes from Chirpstack itself. In a nutshell, the MIC of the JOIN REQUEST is computed based on the message content and the AppKey. If it always happens, either the message is somehow always received incorrectly or the key is wrong (thus always being unable to decrypt the message/validate the MIC).

You’re using the same LoRa gateway, so the hardware should be physically okay. Have you checked that the channels are correctly configured? If it somehow cannot receive the message correctly all the time, it may be an indicator that something is causing a very high error rate.

[jka]

hmm I think more and more that my gateway have a problem, it is correctly configured… but it also send always two times a event up massage, that’s not normal or?

And than I get sometimes this error:
ERROR chirpstack::uplink: Deduplication error error=Unexpected m_type: UnconfirmedDataDown

Could it be coursed by my wrong working gateway?

[sp193]

From my experience, you can get duplicates on different channels, if your node is too close to the gateway. This may result in an “echo”. You may also receive a downlink as an uplink, as an effect of echos. Sometimes, the packet is also malformed in such a way that it passes the weak CRC check at the LoRa outer frame, but fails the MIC check. This is also how you may get uncommon MIC errors, but it is not necessarily a problem.

You could move your node further away from the gateway.
As long as the MIC errors is not a common problem and does not affect packet reception, there is no problem.

LoRa gateways will forward anything that is received. The LNS will do de-duplication, to eliminate the duplicates.

[devleesch001]

I have similar error, the Join Request sent from chirmstack-mqtt-forwarder 4.1.3 are always in mic error.
But I’m sure my AppKeys are valid and the method to check mic is also valid.

I use RAK7268CV2 Gateway, this gateway integrated its own LoRa Gateway MQTT Bridge, compatible Chirpstack, and Semtech UDP GWMP Protocol Forwarder.

Which makes me think that it comes from the Chirpstack Packet Forwarder, its :

• When I use RAK LoRa Gateway MQTT Bridge, Join Request work.
• When I use Semtech UDP GWMP Protocol, Join Request work.
• But when I use Chirpstack-MQTT-Forwarder all Join Request are in MIC ERROR.

But if devices have already joined network, all uplinks (UnconfimedUplink) are valid and all its work (expect JoinRequest).

And more if I get requests sent to chirpstack and I decode it manually, and I check the mic, there is systematically in error only with Chirpstack MQTT Forwarder.

[devleesch001]

I confirm probleme comme from last version 4.1.3

I have install Chirpstack-MQTT-Forwarder version 4.1.2 on an other gateway.

And when I look the message receviec from two gateway LoraFrame I have a divergence on MIC code

[devleesch001]

Same issue for self compiled MQTT-Forwaeder 4.2.0-test.1

[brocaar]

Please see the updated version that was released yesterday: Changelog - ChirpStack open-source LoRaWAN® Network Server documentation.