I installed ttn stack v3 on my private server and got everything working, but when I receive something on the gateway, I get the following error:
Host cluster failed to handle message: No device matches uplink
I already created the application and the end device with matching eui, device addr, network key, app key… I don’t know what is wrong.
Here’s the json with error… Maybe it helps.
If you’re willing to burn a set of secrets, try using the online decoder on the raw packet received by the gateway and see if it really matches the details you configured, or if something got mis-trasncribed or byte reversed.
Yeah, i’m sure…
On the gateway log, I see the device address, wich is correct, but even with the application and end-device created, I’m getting these errors…
If I simulate the uplink, it goes ok…
I’m in doubt with this “link” thing… This is in my application screen, and i’m leaving this network server address empty because the server is the same for everything… does have something to do with it?
It says the application is linked, btw…
Paging @htdvisser for input - @vulcanum_engenharia, mostly it’s TTI staff who are the subject matter experts on the V3 stack but right now they will be busy getting ready for the conference.
I’m afraid I can’t be of much help here. With LoRaWAN, matching an uplink to an device can fail at several points, and it’s often impossible to say what exactly went wrong.
At a high level, the matching process is as follows:
Find all device registrations with the DevAddr that’s in the uplink. This can result in multiple device “candidates”, as DevAddrs are not unique.
For each device registration, try to determine the most likely frame counter. The uplink message only contains half of the actual frame counter. Simply said: an uplink contains xx00 instead of 1200, and the network needs to “guess” what that xx is. Since the LoRaWAN specification dictates that frame counters can only increase, this may result in a wrong “guess” for ABP devices that reset frame counters.
Using that (guessed) frame counter, the NwkSKey (and in case of LoRaWAN 1.1+ some more fields) the network computes the MIC (“signature”) it would expect for this uplink, given those fields. It compares this MIC to the MIC that’s actually in the message. If it matches, great! If it doesn’t match, it’s impossibly to say why.
In most cases, device matching failures occur with ABP devices, which is why we always recommend using OTAA. If you’re already using OTAA, try to make the device perform a new join procedure. If the join procedure succeeds, but subsequent uplinks fail, we’d need to take a closer look.
