MIC mismatch with OTAA

Hello,
I am working as an intern and exploring 1WL EVK.
I have managed to successfully passthrough data to the network server through our RAKwireless (RAK747268) gateway. I am currently using Things network (Third party) as our network server and intend to integrate TTN with Abeeway Device manager through Abeeway location engine.
I am facing MIC mismatch error at the network server side. All the preliminary investigations points to appKey mismatch between the network server and the device.
Note:I have used OTAA. I have overwritten factory default JoinEui with all zeros (0000000000000000) and using custom appKey, matching to the values inputted in the network server. The appKey is set by flashing the manufacturing firmware and using command “provis lora set appkey XXX”.

  1. Is there a way to verify(read and confirm) the appKey?

  2. If I want to use the factory settings, can I go back to the factory configurations ? (We have factory devEui & joinEui but no appEui)

Appreciate any other suggestions, on overcoming this MIC mismatch error. Kindly request your help and support.

This is the event details.
{
“name”: “ns.up.join.cluster.fail”,
“time”: “2025-07-03T11:02:24.131697028Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “1wl-evk”,
“application_ids”: {
“application_id”: “1wl-new”
},
“dev_eui”: “20635F01F0019AEA”,
“join_eui”: “20635F0000000001”
}
}
],
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/joinserver”,
“name”: “mic_mismatch”,
“message_format”: “MIC mismatch”,
“correlation_id”: “42b645719e4947f79ef65e1220f872a8”,
“code”: 3
},
“correlation_ids”: [
“gs:uplink:01JZ7Z7CKTX325B0PJ652XAAX5”
],
“origin”: “ip-10-100-7-207.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01JZ7Z7CM31SZPN6YB3W4PG2BQ”
}

Maybe this is the problem?

That looks suspicious indeed, but entering a different JoinEUI should result in the activity not even being routed to that device on TTN. But it also raises the question whether the custom AppKey was entered successfully - likely not.

Thanks for the response,
I initially performed a factory reset on the device and changed the joineui from 20635F0000000001 to all zeroes. The 1wl evk end device comes with its own factory set joineui and deveui. Since I was encountering the MIC mismatch from the beginning I temporarily set to all zeroes. However it didn’t show any improvements so I reverted back to original joineui 20635F0000000001 given by the evk.
I am sorry for the confusion I caused by misattributing the relation between event logs and JoinEUI. I want to correct it by telling that the joineui is correctly set to 20635F0000000001(factory set) but I am still facing the mic issue.
And as you said there might be issue with custom set appkey and there is no way I can check unlike joineui and deveui.

In the user guide they have mentioned this:
“The LoRa parameters (DevEUI, Network and
Application keys) must be provisioned. Note that the initial provisioning is done by the manufacturer and
the LoRa region is set to EU868 (Europe). The provisioning can be modified by the
aos_provisioning facility.”

But I am not exactly sure how to implement this.
Can someone please help me with this as soon as possible.

Without knowing the details of the device manufacturer & part number and making it easy on us volunteers to read the manual, a link, this may take some time! Sure, we can Google “1WL EVK” but is it what you have?

Murata Part Number: LBEU5ZZ1WL-633EVK

1 Like



These are the snap shots of LR1110 service provided in the SDK user manual

Both of these imply that there is some sort of command line interface which isn’t really very obvious in the documentation you’ve linked to. Where did you get the details on the provis lora set appkey command?

For many of these serial configured modules, you just have to read back the DevEUI, Join(App)EUI and AppKey and then use those on the console using Copy & Paste, taking care to select the correct version of LoRaWAN.

Why are you using this module? Can you use something simpler?

What do ThingPark/Actility say when you ask them about this issue?

Have you been given this todo by someone that knows LoRaWAN or are they hoping you will learn everything and teach them after? If the former, what do they say, if the latter, leave now whilst you still have your sanity!