This guide helps you to troubleshoot network-server related connectivity issues. This guide assumes that your gateway is connected and that the ChirpStack Gateway Bridge is publishing the received data. If you are not sure, please refer to the Gateway troubleshooting guide. It also assumes that you have setup the ChirpStack Network Server and ChirpStack Application Server component and that you have setup your gateway and device through the web-interface.
In this guide we will validate:
To find out if ChirpStack Network Server is receiving messages from your gateway, you should refer to the logs. Depending how ChirpStack Network Server was installed, one of the following commands will show you the logs:
journalctl -f -n 100 -u chirpstack-network-server
tail -f -n 100 /var/log/chirpstack-network-server/chirpstack-network-server.log
INFO backend/gateway: uplink frame received INFO device gateway rx-info meta-data saved dev_eui=0101010101010101 INFO device-session saved dev_addr=018f5aa9 dev_eui=0101010101010101 INFO finished client unary call grpc.code=OK grpc.method=HandleUplinkData grpc.service=as.ApplicationServerService grpc.time_ms=52.204 span.kind=client system=grpc
In this log, ChirpStack Network Server has processed the uplink frame, and forwarded the
application payload to the
(provided by ChirpStack Application Server).
INFO backend/gateway: uplink frame received ERRO processing uplink frame error data_base64="QKlajwGCAgADBwF6Eabhjw==" error="get device-session error: device-session does not exist or invalid fcnt or mic"
In this log, ChirpStack Network Server was unable to authenticate the received data and map this to a device-session. The cause could be:
Try to re-activate your device. The activation did not match any of the device-sessions stored in the database. After a long time of inactivity, it could have expired. Also make sure that the LoRaWAN® version selected in the Device-profile matches the implemented LoRaWAN® version by the device!
In case of an ABP device, there are a couple of things that could case this error:
First of all, make sure that the session-keys are entered in the correct
byte-order. Some devices expect little-endian, some big-endian and in some
cases these are mixed. One suggestion to find this out is by starting with
a key where
the order does not matter.
When the error is raised after the device was reset (e.g. power-cycle) then
the issue is likely related to a frame-counter reset. A LoRaWAN® Network Server
must check that the frame-counter is incremented, if not it will be rejected.
This is to protect the network against replay-attacks. The problem is that most
ABP devices reset their frame-counters to
0 on a power-cycle, which is not
in line with the LoRaWAN® specification.