[release] LoRa App Server 0.15 & LoRa Server 0.23

brocaar · December 8, 2017, 10:19am

I’ve just released LoRa App Server 0.15.0 and LoRa Server 0.23.0. This release includes a downlink device-queue refactor (the downlink queue is now stored by LoRa Server).

As always, make a backup before upgrading

Changelogs

LoRa App Server

0.15.0

Changes:

Downlink device-queue
- Downlink device-queue has been moved from the LoRa App Server database to
  the LoRa Server database.
- LoRa App Server sends nACK when no confirmation has been received on
  confirmed downlink transmission. See ACK notifications.
- LoRa App Server will not re-try transmitting a confirmed downlink anymore.
- ACK and error notifications now contain the fCnt to which the notification is related.
- The downlink-queue is now flushed on a (re)activation.
Downlink device-queue API (/api/devices/{devEUI}/queue)
- Removed DELETE /api/devices/{devEUI}/queue/{id} endpoint (as removing
  individual device-queue items will give fCnt gaps).
- Added DELETE /api/devices/{devEUI}/queue to flush the whole device-queue.
Class-C
- Class-C timeout (see device-profiles)
  has been implemented for confirmed downlink transmissions. Make sure to
  update this value for existing Class-C device-profiles to a sane value.

Bugfixes:

Fix organization pagination (thanks @jcampanell-cablelabs)

Improvements:

Use RFC1945 Authorization header format (thanks @fifthaxe)

LoRa Server

0.23.0

Features:

The management of the downlink device-queue has moved to LoRa Server.
Based on the device-class (A or C and in the future B), LoRa Server will
decide how to schedule the downlink transmission.
LoRa Server sends nACK on Class-C confirmed downlink timeout
(can be set in the device-profile) to the application-server.

Changes:

Working towards a consistent and stable API, the following API changes have
been made:

Application-server API

HandleDataDownACK renamed to HandleDownlinkACK
HandleDataUp renamed to HandleUplinkData
HandleProprietaryUp renamed to HandleProprietaryUplink
GetDataDown has been removed (as LoRa Server is now responsible for the
downlink queue)

Network-server API

Added
- CreateDeviceQueueItem
- FlushDeviceQueueForDevEUI
- GetDeviceQueueItemsForDevEUI
Removed
- SendDownlinkData

Note: these changes require LoRa App Server 0.15.0 or higher.

brocaar · December 8, 2017, 10:38am

As a side-note: these changes will also make it much easier to implement your own application-server for LoRa Server, as more LoRaWAN logic has been moved to LoRa Server

xeee · December 8, 2017, 10:45am

Both packages updates on the Debian / Ubuntu version and everything seems to be OK.
As a sidenote, the package is labeled as 0.23.

apt list loraserver
Listing… Done
loraserver/unknown,now 0.23.0 amd64 [installed]

brocaar · December 8, 2017, 10:58am

I made a really consistent typo in this announcement 0.23.0 is the correct version so you’re good!

Richa · December 12, 2017, 6:15am

Problem with LoRa server 0.23

Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“starting LoRa Server” band=“EU_863_870” docs=“https://docs.loraserver.io/” net_id=010203 version=0.23.0
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“setup redis connection pool” url=“redis://localhost:6379”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“connecting to postgresql”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“backend/gateway: connecting to mqtt broker” server=“tcp://localhost:1883”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“setup application-server client pool” ca_cert= tls_cert= tls_key=
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“configuring join-server” ca_cert= server=“http://localhost:8003” tls_cert= tls_key=
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“no network-controller configured”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“applying database migrations”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“backend/gateway: connected to mqtt server”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“backend/gateway: subscribing to rx topic” topic=“gateway/+/rx”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“backend/gateway: subscribing to stats topic” topic=“gateway/+/stats”
Dec 12 10:41:50 ubuntu loraserver[28654]: time=“2017-12-12T10:41:50+05:30” level=info msg=“migrations applied” count=0
Dec 12 10:41:50 ubuntu systemd[1]: loraserver.service: Main process exited, code=exited, status=1/FAILURE
Dec 12 10:41:50 ubuntu systemd[1]: loraserver.service: Unit entered failed state.
Dec 12 10:41:50 ubuntu systemd[1]: loraserver.service: Failed with result ‘exit-code’.
Dec 12 10:41:51 ubuntu systemd[1]: loraserver.service: Service hold-off time over, scheduling restart.
Dec 12 10:41:51 ubuntu systemd[1]: Stopped LoRa Server.
Dec 12 10:41:51 ubuntu systemd[1]: loraserver.service: Start request repeated too quickly.
Dec 12 10:41:51 ubuntu systemd[1]: Failed to start LoRa Server.

Please suggest where is the issue.

brocaar · December 12, 2017, 8:06am

Could you start loraserver manually? It seems that journalctl somehow does not show the last logs before error (this has been reported before). You will probably get more info when you run:

set -a
source /etc/default/loraserver
loraserver

Richa · December 13, 2017, 5:27am

richa@richa-Lenovo-G40-80:~$ set -a
richa@richa-Lenovo-G40-80:~$ source /etc/default/loraserver
richa@richa-Lenovo-G40-80:~$ loraserver
INFO[0000] starting LoRa Server band=“EU_863_870” docs=“https://docs.loraserver.io/” net_id=010203 version=0.23.0
INFO[0000] setup redis connection pool url=“redis://localhost:6379”
INFO[0000] connecting to postgresql
INFO[0000] backend/gateway: connecting to mqtt broker server=“tcp://localhost:1883”
INFO[0000] setup application-server client pool ca_cert= tls_cert= tls_key=
INFO[0000] configuring join-server ca_cert= server=“http://localhost:8003” tls_cert= tls_key=
INFO[0000] no network-controller configured
INFO[0000] applying database migrations
INFO[0000] backend/gateway: connected to mqtt server
INFO[0000] backend/gateway: subscribing to rx topic topic=“gateway/+/rx”
INFO[0000] backend/gateway: subscribing to stats topic topic=“gateway/+/stats”
INFO[0000] migrations applied count=0
INFO[0000] starting api server bind=“0.0.0.0:8000” ca-cert= tls-cert= tls-key=
INFO[0000] starting gateway api server bind=“0.0.0.0:8002” ca-cert= tls-cert= tls-key=
FATA[0000] --gw-server-jwt-secret must be set

After setting above variable its working perfect.
Thanks a lot

lorenzo75 · December 19, 2017, 2:49pm

I have 2 issue:

the device_queu_mapping is not created at startup. The migrations exit at nr 0021_user_email_and_note so the 0022_add_device_queue_mapping is not executed
following this problem I discover that in the actual repository there is no more migrations package in internal directory even if there is an import in main.c

What I’m missing?
Thaks

brocaar · December 19, 2017, 2:51pm

Are you using the pre-compiled binary?

The migrations exit at nr 0021_user_email_and_note so the 0022_add_device_queue_mapping is not executed

With an error?

following this problem I discover that in the actual repository there is no more migrations package in internal directory even if there is an import in main.c

There is no main.c Please note that the internal/migrations are generated during make.

lorenzo75 · December 19, 2017, 2:56pm

Thnk you and sorry for typo error.

By the way the log says : migrations applied count=0

I run go bindata to generate correct sql files but then I had to generate the table manually using psql and parsing the 0022 file.

brocaar · December 19, 2017, 3:00pm

Again the question, were you using your own compiled version of LoRa App Server, or are you using the pre-compiled binaries.

I run go bindata to generate correct sql files

I take that as you have your own compiled version? In that case it will be hard for me to tell what went wrong … Upgrading from pre-compiled binary to a new version of the pre-compiled binary should be without any issues. However when you compile your own binaries and make your own changes or are not strictly following the master branch, then there are a lot of things that could mess up the data.

lorenzo75 · December 19, 2017, 3:13pm

Yes I’m compiling sources by myself… following the master branch.

I downloaded the git files and ran “make requirements” and then “make build”

Is this incorrect?

brocaar · December 19, 2017, 3:41pm

That should be fine However it is still hard for me to give feedback at what went wrong (I’m doing a lot of testing between tagged releases, however it could be that you migrated your database to an state in-between two tagged releases which messed up the migrations). What you could check is the gorp_migrations table in the database. That is the “checklist” of all applied migrations.