MIC invalid


As I am referring the TTN forum for my issue that the in the device application console I receive on the device join request not receive any data and in the gateway console receive the join request and join accept only. So I refer below topic:


I got the information about the online LoRaWAN packet decoder and I try to decode the Join accept payload that show me that MIC is invalid. I am stuck now please help me with that.

I am also attache some SS for your reference. Waiting for valueable help.testing2 final

Note that the online decoder states:

OTAA Join Accepts are not fully supported above, as those need some additional data to validate their MIC and derive the secret session keys.

So, it cannot validate the MIC and I guess I could make the warning even more explicit.

As your TTN Console screenshots show a value for DevAddr, TTN actually accepted the Join Request, and probably indeed commanded a gateway to transmit the Join Accept. Most likely, the node did not receive it.

Thank for the response. So can you suggest me to resolve this issue what can i do?

Idrop1 drop2

Here I am attaching the some SS that I did not receive the uplink message please help me with that how can I resolve this problem.

It’s hard to tell from your screenshots which Join Accept (green icon) goes with which Join Request (orange icon), but it seems the timing might be tight. Like: assuming that the 12:49:59 Join Accept goes with the 12:49:53 Join Request, then that’s about 6 seconds difference, while for RX1 it should be 5 seconds, and also needs some time to send the Join Accept to the gateway. (The frequency and SF of the Join Accept shows that it’s supposed to be RX1, not RX2, which for India would be 866.550 SF10.)

So: are you using a router and handler that is within your region? (I’d guess ttn-handler-asia-se for the application, and something similar for the gateway.)

If the gateway still accepted the command to transmit the Join Accept, then maybe your node is not receiving the Join Accept as it’s expecting it a bit earlier. If this happens to be using LMIC then see LMIC’s MAX_CLOCK_ERROR to relax timing issues a bit. For other nodes, I don’t know.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.