Hello all,
I work in a lab where we use a fair number of LoRa nodes with various Chirpstack instances. Today I noticed that one instance (running 4.10.2) was receiving a lot of repeated packets:
Indeed, these packets all had the exact same payload and frame count - the only difference was that the frequencies were slightly different. (We use US915, so they were something like 9039…, 9045…, 9053…).
Usually, Chirpstack knows to de-duplicate these packets, but in this case it did not. Digging into the logs, I found the (probable) reason why: (logging set to DEBUG here)
2025-07-17T20:38:01.976981Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_id="us915_2" topic=us915_2/gateway/thisismygatewayid/event/up qos=AtMostOnce json=true
2025-07-17T20:38:02.182086Z INFO up{deduplication_id=231c7edb-8805-4eb8-860e-4d9a74b02e07}: chirpstack::uplink: Uplink received m_type=UnconfirmedDataUp
2025-07-17T20:38:02.182159Z DEBUG up{deduplication_id=231c7edb-8805-4eb8-860e-4d9a74b02e07}: chirpstack::uplink: Updating gateway meta-data for uplink frame-set
2025-07-17T20:38:02.184891Z DEBUG up{deduplication_id=231c7edb-8805-4eb8-860e-4d9a74b02e07}: chirpstack::uplink: Logging uplink frame to Redis Stream
2025-07-17T20:38:02.191450Z INFO up{deduplication_id=231c7edb-8805-4eb8-860e-4d9a74b02e07}:data_up: chirpstack::uplink::data: No device-session exists for dev_addr dev_addr=01e09d85
This problem has been around for a while, so earlier we upgraded the Chirpstack instance from 4.6 to 4.10.2 (on the advice of this related post). After installing the new package, I ran the command below as recommended by this post to migrate the session information over.
All was well, and indeed the session information did migrate, but the issue persisted, as you can see above. To confirm that there was no session information, I checked both the Redis (to be safe):
127.0.0.1:6379> KEYS "devaddr:{01e*"
(empty array)
and the postgres db:
postgres=# \c chirpstack
You are now connected to database "chirpstack" as user "postgres".
chirpstack=# select dev_addr from device;
dev_addr
-----------
\x0161146d
\x018fa289
\x00113e6c
\x0066c170
\x01150259
\x0118c3e8
\x0093d247
\x001d3c78
\x00d9d2b4
\x00b49dc0
\x005ec1f3
\x00b177c5
(12 rows)
So Chirpstack is right, there is no session information for this device. (I could have confirmed this through the web UI, and indeed I did, but I wanted to be sure.)
The question is: if there is no session information for this device, then why is it sending packets with the gateway ID of this gateway? What makes it think that the gateway will respond?
The only related post I can find is this one, which suggests that there was at one point a session for the device which was then dropped without the device knowing. However, I am pretty confident that this was not the case. So: why is this happening? is there a way to make Chirpstack just ignore the packets, rather than attempt to parse each one?
Thanks!
,