[release] LoRa Server v2.8

LoRa Server v2.8.0


Add mqtt2to3 sub-command

This sub-command translates MQTT messages from the old topics to the new topics (gw > ns) and backwards (ns > gw) and should help when migrating from v2 to v3 MQTT topics (see below).

This sub-command can be started as (when using the Debian / Ubuntu package):

  • /etc/init.d/loraserver-mqtt2to3 start
  • systemctl start loraserver-mqtt2to3

From the CLI, this can be started as:

  • loraserver mqtt2to3

As soon as all LoRa Gateway Bridge instances are upgraded to v3, this is no longer needed.

Azure integration

Using the Azure integration, it is possible to connect gateways using the Azure IoT Hub service. This feature is still experimental and might (slightly) change.


As a preparation to upgrade to LoRa Server v3, it is recommended to update the MQTT topic configuration to:

downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"

Together with the mqtt2to3 sub-command (see above), this stays compatible with LoRa Gateway Bridge v2, but also provides compatibility with LoRa Gateway Bridge v3. Once LoRa Server v3 is released, it is recommended to first upgrade all LoRa Gateway Bridge instances to v3 and then upgrade LoRa Server to v3.

LoRa Server v2.8.1


Validate DevAddr on enqueue

A DevAddr field has been added to the MulticastQueueItem API field. When this field is set, LoRa Server will validate that the current active security-context has the same DevAddr and if not, the API returns an error.

This prevents enqueue calls after the device (re)joins but before the new AppSKey has been signalled to LoRa App Server.


Thanks! I see an app-server 2.6.1 tag on Docker Hub, I will look forward to loraserver 2.8.1 there as time allows. :+1:

Hii @brocaar

after upgrading loraserver v2.8.1 we have started 2 nodes of MAC v1.1.x but 1 nodes was not joining (problem with JoinAccept ack to node or rx2timeout issue)
it will working automatically after 2-3 min but another node was not working (STATUS: BUSY)

###### ===== MLME-Confirm ==== ######
STATUS      : Rx 2 timeout

in previous version of loraserver it will work
only 1 node was working at a time

ISM Band: EU433

can you please help me…!
Thank you

I’m not sure how this could be related to the v2.8.1 changes. If you think this is a bug, could you provide instructions (as specific as possible) how I can reproduce this?

Thanks @brocaar

  1. In older version we have tested LoRaWAN v1.1.x 3 devices were working perfectly at a same time.
  2. When we upgraded to latest version of LoRaServer & Lora App Server and tried to test all v1.1.x 3 devices running same time, We have seen strange behavior. See below
  • When we are starting 3 devices, our first device is working fine but other 2 devices are not getting JoinAccept ACK or rx2timeout so they are sending JoinRequest again
  • after some time 2nd or 3rd device successed and able to work normally, however then our 1st devices loose its connectivity and it doesn’t get ACK so it moves to BUSY state.
  • So we observed that at the given time, only one device is able to work successfully

I have double-checked, but I can not reproduce this issue. Have you checked your logs on errors?


we cannot get any errors in log, we are getting only warning.

time="2019-05-07T17:50:23+05:30" level=warning msg="link_adr request not acknowledged" channel_mask_ack=true data_rate_ack=false dev_eui=xxxxxxxxxxxxxx18 power_ack=true
time="2019-05-07T17:50:30+05:30" level=warning msg="link_adr request not acknowledged" channel_mask_ack=true data_rate_ack=false dev_eui=xxxxxxxxxxxxxx94 power_ack=true

Can you please help us…?
Thank you

Please look into the live LoRaWAN frame logs to see what LoRa Server is requesting in the LinkADRReq and if this (data-rate) is valid for your device region. If it is a valid data-rate, you need to find out why your device is rejecting it.

Our LoRaWAN frame logs

ISM Band: EU433

The data-rate is valid according to the LoRaWAN Regional Parameter specifications, but your device does not accept it (for whatever reason):

This is not an issue related to your LoRa Server update to 2.8.1. You could update your service-profile to for example Max DR: 5 and see if your devices accept that data-rate.

1 Like

Thank you @brocaar

Max DR: 5 in service-profile works successfully.

The end-device is refusing DR6 because the region default channels don’t support the given datarate.

In regional parameters specification the EU433 default channels are defined as shown below:

As you can observe the maximum datarate that can be used on default channels is DR5.

Please also note that the specification doesn’t allow the modification of default channels parameters.

This means that the network server should not attempt to set a datarate bigger than DR5 when only the default channels are enabled.

If one wants to use higher datarates than DR5 then he must define new channels, on the network server and on the gateway, using the full datarate range. [DR0…DR7]

Thanks @mluis1

if i want to use higher data rate then DR5 must be define new channel in


# Extra channel configuration.
  # [[network_server.network_settings.extra_channels]]
  # frequency=867100000
  # min_dr=0
  # max_dr=5


Add extra channel configuration in gateway-profile.

if we use higher datarates then DR5 so it will impact on range?
if we use more than 5 devices same time on 1 gateway so it will work?

You must define them in loraserver.toml.

Hey @all

after upgrading from loraserver 2.5.0 to 2.8.1 i have problems with the spreading-factor. while in version 2.5.0 i have SF 7 from my testdevice, i have now SF 12.

i tried the following so far:

  • same config file for version 2.5.0 in 2.8.1.
  • create a new config file out of the binary and changed all my config stuff (redis, mqtt, postgres).

i can reproduce this error by creating a new instance in version 2.5.0 and use 2.8.1 then.

questions are:

  • does anybody has a idea how to fix this?
  • do i have to use the different steps (maybe 2.5.0 to 2.6.0, to 2.7.0 and so on

any help would be nice,
thx and regards,


How is your service-profile configured with regards to min / max DR?

as i am not really understand this, i added 1 on min and 100 on max. i do more researches on this.

Please refer to the LoRaWAN Regional Parameters to find the min / max allowed data-rates for your region.

first of all, thx for your help. i found this on the LoRaWAN Regional Parameters for EU:

so i set the values to min 0, max 6, and i tried with 0 and 7, but the issue is the same