Device security-context out of sync

I’m trying to send a data to the end node using “/api/devices/{device_queue_item.dev_eui}/queue”
Actually, it was working several days ago. but today it responds an error message below.

    {
  "error": "enqueue downlink payload error: create device-queue item error: rpc error: code = InvalidArgument desc = device security-context out of sync",
  "message": "enqueue downlink payload error: create device-queue item error: rpc error: code = InvalidArgument desc = device security-context out of sync",
  "code": 13,
  "details": []
}

Please give me an advice.
This is what I sent.

This happens when the device OTAA joined (again), but LoRa Server did not signal the new AppSKey to LoRa App Server because it didn’t receive a first uplink yet.

Thus, the LoRa App Server security-context is not in sync during a short interval which causes the above error.

@brocaar

we are also facing this issue. What is the root cause of this issue?

What is the solution to this type of error, assume we have deployed so many devices in fields and occurs this type of issue what should we do on-field scenario.

Thanks

This happens when the device OTAA joined (again), but LoRa Server did not signal the new AppSKey to LoRa App Server because it didn’t receive a first uplink yet.

Wait until the device sends its first uplink.

1 Like

Yes, but my device is working perfectly and suddenly server shows context security out of bound error and All the counter will be 0.

Over the course of the life of a device (or battery), the time between the join and the first uplink should be a very small percentage - i.e. it should not happen very often. Is your device rejoining regularly?

No, first time we are facing this issue

I understand not happen every time, @bconway any solution if this issue occurs in the real field?

Thanks for your reply

We configured our services that sit on top of ChirpStack to queue the message until it can be successfully queued in ChirpStack. The same approach works for devices that have been registered but never joined, which also cannot queue downlinks in ChirpStack.

1 Like

So, this means there is currently no way to send data in first DL (which comes after first UL after Join)?

Or can you enqueue the DL during get_downlink_data_delay already?

Or can you enqueue the DL during get_downlink_data_delay already?

Yes, there is a time-window between receiving the (first) uplink and when ChirpStack reads the queue, in which you can enqueue the downlink.

This is going to be easier in the future ChirpStack release :slight_smile: I’m currently refactoring and cleaning up the code-base, which will also remove the limitation that you have to wait with the enqueue until the first uplink (nothing public yet).

1 Like

I’m getting such an error while trying to enqueue a downlink through the App Server:

A little background: the device keeps sending uplink messages successfully. I’ve waited for the “next uplink” and the error is persistent. I thought it could be related to the fact I was using replicas of the ns/ap server (based on wobcom / iot / Chirpstack Helm · GitLab), but them I scaled-down to one instance of each server and the error is still persistent.

EDIT:
Chirpstack App Server: 3.17.6
Chirpstack Net Server: 3.16.1

Could you check if the device re-joined before sending the payload. That might trigger that.

I can’t assure that it has joined after the last change I’ve made to the NS/AP instances: I’ve made several tests along with helm chat deployments options. However, I may say that all the tests were using the same DB (Postgres and Redis), so I’d expect that sessions keys would be properly stored. In fact, I’ve disabled such a device to force end-device rejoin mechanism and, after that, the problem was solved.

Seeing similar issue with a device that primarily works with downlink data (an indicator light). It joins and then doesn’t send an uplink for a long time. So app (Python) using API sees repeated:

debug_error_string = "{"created":"@1649872152.056108020","description":"Error received from peer ipv4:192.168.1.55:8080","file":"src/core/lib/surface/call.cc","file_line":903,"grpc_message":"enqueue downlink payload error: create device-queue item error: rpc error: code = InvalidArgument desc = device security-context out of sync","grpc_status":13