[release] ChirpStack Network Server v3.11

ChirpStack Network Server v3.11.0


Passive roaming

This release provides an experimental implementation of the Passive Roaming implementation as specified by the LoRaWAN Backend Interfaces v1.0.0 specification.


Improve uplink de-duplication

This removes the de-duplication that was also performed by the MQTT backend. It also updates the current deduplication function to include the full TXInfo within the de-duplication key. Uplinks received on multiple channels will therefore be processed (and MIC validated) separately.

Add stats interval to gateway profile

This makes it possible to set the gateway stats interval when supported by the gateway (currently only Concentratord is supported).

Internal join-server cleanup

This removes old join-server code on favor of the client code which is also used for Passive Roaming (as both are based on the LoRaWAN Backend Interfaces specification).

Expose gateway expiration date

When creating a gateway certificate, the expiration is now exposed in the API response.

Join-server DNS resolving

When no join-server is pre-configured, DNS resolving is enabled and the JoinEUI does resolve, the the same certificate configuration will be used as when connecting to the default join-server.

Add tls_enabled option to Redis config.

In earlier releases, it was possible to configure the Redis endpoint by URL, which allowed to enable TLS. The configuration changed when support for Redis Sentinel and Redis Cluster was implemented. This adds back the option to enable TLS.


  • Always respond to RXParamSetupAns requests. (#493)
  • Fix healthcheck -> health log line. (#505)

Thanks for the release. A little background (I believe) on the de-duplication using full TXInfo:

Keep those installations up to date!

I’m aware of that article, but the main message is: make sure your MQTT authentication / authorization is setup correctly:

The power of this security issue lies in an MQTT Authorization misconfiguration.

The TXInfo de-duplication change is not going to change much as for LoRaWAN 1.0.x, the MIC check does not consider the uplink channel. That is implemented in LoRaWAN 1.1.x.

If you are able to send a valid uplink with wrong parameters (e.g. uplink frequency) before a valid uplink + valid parameters reaches the NS, then the de-duplication with the wrong parameters will be handled first and the downlink is sent on a wrong channel and therefore never received by the device. As well, your malicious gateway could claim a higher SNR / RSSI and therefore the NS will select your gateway to route the downlink.

As gateways provide important meta-data which is used for routing the downlink messages, it is important to trust the gateways that are connected to your network. Therefore only trusted gateways should be able to connect to your network.

But all of that relies on the physical security of low-cost device deployed in the field. Have you found any gateways that aren’t trivial to extract credentials/certs from? I haven’t. I think upstream defense is especially important in scenarios where people don’t necessarily notice or care that a gateway goes missing.

I completely agree with you on that. But note that the article covers the LoRaWAN 1.1.x MIC checking, in case of LoRaWAN 1.0.x, the uplink channel is not part of the MIC thus the NS can not distinguish between a good and bad frequency (assuming these are two valid frequencies for that region, e.g. they both translate to a channel number). In which case the uplink will be delivered to the AS, but the downlink path will be broken as the NS will use the wrong frequency for the downlink.

I don’t think there is any way to prevent all attack vectors, other than making sure that in case a gateway is compromised, it is no longer allowed to connect to the network. E.g. even if you are using LoRaWAN 1.1.x, you still have to trust that the reported SNR and RSSI is correct as this is used for deciding which gateway will be used for the downlink path.

1 Like