brocaar / chirpstack-network-server Goto Github PK

View Code? Open in Web Editor NEW

1.5K 149.0 544.0 8.78 MB

ChirpStack Network Server is an open-source LoRaWAN network-server.

Home Page: https://www.chirpstack.io

License: MIT License

Makefile 0.13% Go 99.41% Shell 0.41% Dockerfile 0.05%

lora lorawan iot network-server internet-of-things loraserver lora-server

chirpstack-network-server's Introduction

ChirpStack Network Server

ChirpStack Network Server is an open-source LoRaWAN network-server, part of ChirpStack. It is responsible for handling (and de-duplication) of uplink data received by the gateway(s) and the scheduling of downlink data transmissions.

!!! ChirpStack v4 note !!!

With the release of ChirpStack v4, the source-code has been migrated to https://github.com/chirpstack/chirpstack/. Please refer to the v3 to v4 migration guide for information on how to migrate your ChirpStack v3 instance.

Architecture

Component links

License

ChirpStack Network Server is distributed under the MIT license. See also LICENSE.

chirpstack-network-server's People

Contributors

Stargazers

Watchers

Forkers

blaet magicking sirfragles acklio apelov yansyaf swiatecki chengshiyegui lda2000 liuken dariobottazzi anselzhanggit wangeshen diiegg khush-bhatia accurate2014 emuxevans bearxiong99 sunblade redbeardlab zhihual charliexp virterm mehradzie ccceeefff jmptrader opensourcetycoon guailong618 bcatalin deeps-lee ooitomato cxcco yuseunghyuk jiapengli eliatrope38 sebde aline1029 mythfish k4jt ericnjin sacoku julien-ioic linux4life798 lancezhangsf lisidan jungok fred-jenn-alet radekvozak samerlahoud alamkamran sandrourban manggapu ymkins sinkableshoal albertwow80 joyzhang15 denisghub gzpanxb jcampanell-cablelabs hktt steffensiewert wysdhl2005 tuxiaopeng yabinhu prothesman caicaide davion12 donadonny fifluisa jongho24 andreilutcenko silviobiki shengyewang demontefacto tonetong reixd malenn emone ahisayoshisuehiro kerasking shauew lukejin-dev willwil rolandvs hongbinz jason-zhou2014 sepppenner hilerchyn norazamaziz mhadjmoh mario83 roodsoft joriwind orinocoz zhehe ghw103 balte michailpot mitlab piaoxuebingfeng

chirpstack-network-server's Issues

[GOLANG] Importing local packages but with the "github.com/brocaar/" prefix?

I am new to Go, so please pardon me if this question is stupid.

When I pull down the loraserver repo, and do make, I get errors like
internal/loraserver/interfaces.go:4:2: cannot find package "github.com/brocaar/loraserver/models" in any of: ........

internal/loraserver/loraserver.go:12:2: cannot find package "github.com/brocaar/loraserver/models" in any of:.........

If I change all the "github.com/brocaar/loraserver/....." to "loraserver/......", then the code compiles.

I am using GO 1.6 and my GOPATH and GOROOT are setup correctly. What I don't understand is that, why are we prepending loraserver with github.com/brocaar/? Isn't loraserver a local package instead of a vendor package?

Thanks in advance.

Could not decode RxPacket: invalid characters

loraserver_1 | time="2016-04-24T14:47:08Z" level=error msg="gateway/mqttpubsub: could not decode RXPacket: invalid character 'ÿ' after top-level value" data_base64="Mv+HAwEBCFJYUGFja2V0Af+IAAECAQZSWEluZm8B/4oAAQpQSFlQYXlsb2FkAf+OAAAA/7H/iQMBAQZSWEluZm8B/4oAAQ0BA01BQwH/hAABBFRpbWUB/4YAAQlUaW1lc3RhbXABBgABCUZyZXF1ZW5jeQEIAAEHQ2hhbm5lbAEGAAEHUkZDaGFpbgEGAAEJQ1JDU3RhdHVzAQQAAQpNb2R1bGF0aW9uAQwAAQhDb2RlUmF0ZQEMAAEEUlNTSQEEAAEHTG9SYVNOUgEIAAEEU2l6ZQEGAAEIRGF0YVJhdGUB/4wAAAAR/4MGAQEFRVVJNjQB/4QAAAAQ/4UFAQEEVGltZQH/hgAAACf/iwMBAQhEYXRhUmF0ZQH/jAABAgEETG9SYQEMAAEDRlNLAQYAAAAW/40FAQEKUEhZUGF5bG9hZAH/jgAAABD/jwYBAQRNSERSAf+QAAAAE/+RBgEBB1BheWxvYWQB/5IAAAAO/5MBAQL/lAABBgEIAABm/4gBAQh/BAYISwIAAAL8sZP9rAH9JItAAQIBAQECAQRMT1JBAQM0LzUBeQH4ZmZmZmZmIEABHQEBCVNGMTJCVzEyNQAAAR4BgEEl6KEAAwACXo9uywBsXNfq4m6UHgUzdutLLeYA"

What could be the problem for above errors?

LinkCheckAns

Hi!
I am new to lorawan and i have a device that makes LinkCheckReq. Is it possible to implement it with LinkCheckAns on the loraserver for automatic reply-answer to the device?

Try to build LoraServer but error occured

go get github.com/brocaar/loraserver/...
then use commend 'make build' to build from the source code but error occur:

github.com/jmoiron/sqlx

../../jmoiron/sqlx/bind.go:142: undefined: strings.IndexByte
../../jmoiron/sqlx/sqlx.go:603: db.Ping undefined (type *DB has no field or method Ping)

github.com/garyburd/redigo/redis

../../garyburd/redigo/redis/conn.go:97: undefined: net.Dialer

github.com/Sirupsen/logrus

../../Sirupsen/logrus/writer.go:19: method logger.Debug is not an expression, must be called
../../Sirupsen/logrus/writer.go:21: method logger.Info is not an expression, must be called
../../Sirupsen/logrus/writer.go:23: method logger.Warn is not an expression, must be called
../../Sirupsen/logrus/writer.go:25: method logger.Error is not an expression, must be called
../../Sirupsen/logrus/writer.go:27: method logger.Fatal is not an expression, must be called
../../Sirupsen/logrus/writer.go:29: method logger.Panic is not an expression, must be called
../../Sirupsen/logrus/writer.go:31: method logger.Print is not an expression, must be called
../../Sirupsen/logrus/writer.go:41: undefined: bufio.NewScanner

github.com/brocaar/lorawan

../lorawan/phypayload.go:512: function ends without a return statement

github.com/eclipse/paho.mqtt.golang/packets

../../eclipse/paho.mqtt.golang/packets/packets.go:224: function ends without a return statement

github.com/elazarl/go-bindata-assetfs

../../elazarl/go-bindata-assetfs/assetfs.go:141: function ends without a return statement

github.com/rubenv/sql-migrate/sqlparse

../../rubenv/sql-migrate/sqlparse/sqlparse.go:19: undefined: bufio.NewScanner
../../rubenv/sql-migrate/sqlparse/sqlparse.go:20: undefined: bufio.ScanWords
../../rubenv/sql-migrate/sqlparse/sqlparse.go:49: undefined: bufio.NewScanner

github.com/lib/pq

../../lib/pq/conn.go:176: undefined: bufio.NewScanner

github.com/codegangsta/cli

../../codegangsta/cli/context.go:335: function ends without a return statement
make: *** [build] Error 2

anyone has any suggestion？

mqtt connection error

When I start the semtech-bridge and loraserver both, I get following errors:

loraserver:

...
INFO[0001] application/mqttpubsub: connected to mqtt server 
INFO[0001] application/mqttpubsub: subscribing to tx topic  topic=application/+/node/+/tx
ERRO[0001] application/mqttpubsub: mqtt connection error: write tcp 127.0.0.1:54411->127.0.0.1:1883: use of closed network connection 
INFO[0001] application/mqttpubsub: connected to mqtt server 
INFO[0001] application/mqttpubsub: subscribing to tx topic  topic=application/+/node/+/tx
ERRO[0001] application/mqttpubsub: mqtt connection error: EOF 
INFO[0001] application/mqttpubsub: connected to mqtt server 
INFO[0001] application/mqttpubsub: subscribing to tx topic  topic=application/+/node/+/tx
ERRO[0001] application/mqttpubsub: mqtt connection error: EOF 
INFO[0001] application/mqttpubsub: connected to mqtt server 
INFO[0001] application/mqttpubsub: subscribing to tx topic  topic=application/+/node/+/tx
ERRO[0001] application/mqttpubsub: mqtt connection error: EOF 
INFO[0001] application/mqttpubsub: connected to mqtt server 
...

semtech-bridge:

...
ERRO[0007] backend/mqttpubsub: mqtt connection error: write tcp 127.0.0.1:54468->127.0.0.1:1883: write: broken pipe 
ERRO[0007] backend/mqttpubsub: mqtt connection error: EOF 
INFO[0007] backend/mqttpubsub: connected to mqtt server 
INFO[0007] Backend/mqttpubsub: re-registering to gateway topics  topic_count=1
ERRO[0007] backend/mqttpubsub: mqtt connection error: EOF 
INFO[0007] backend/mqttpubsub: connected to mqtt server 
INFO[0007] Backend/mqttpubsub: re-registering to gateway topics  topic_count=1
INFO[0007] backend/mqttpubsub: connected to mqtt server 
INFO[0007] Backend/mqttpubsub: re-registering to gateway topics  topic_count=1
ERRO[0007] backend/mqttpubsub: mqtt connection error: EOF 
INFO[0007] backend/mqttpubsub: connected to mqtt server 
INFO[0007] Backend/mqttpubsub: re-registering to gateway topics  topic_count=1
ERRO[0007] backend/mqttpubsub: mqtt connection error: EOF 
INFO[0007] backend/mqttpubsub: connected to mqtt server 
INFO[0007] Backend/mqttpubsub: re-registering to gateway topics  topic_count=1
...

I only get these mqtt packets:

gateway/b827ebfffee35329/rx {"rxInfo":{"mac":"b827ebfffee35329","time":"2016-05-20T12:57:52.481279Z","timestamp":111316044,"frequency":868300000,"channel":8,"rfChain":1,"crcStatus":1,"codeRate":"4/5","rssi":-16,"loRaSNR":9.5,"size":29,"dataRate":{"modulation":"LORA","spreadFactor":7,"bandwidth":250}},"phyPayload":"QJt7o82ABQACoYFmhN89oWNyYUotAX8qvBoFAR8="}

But no application packets.

use docker to run v0.8.0, connect MQTT broker timeout

$ ./loraserver --db-automigrate --net-id 010203 --band EU_863_870 --postgres-dsn "postgres://dbuser:[email protected]/loraserver?sslmode=disable" --redis-url "redis://192.168.10.11:6379" --gw-mqtt-server "tcp://test.mosquitto.org:1883" --app-mqtt-server "tcp://test.mosquitto.org:1883"
INFO[0000] starting LoRa Server band=EU_863_870 net_id=010203 version=0.8.0
INFO[0000] connecting to postgresql
INFO[0000] setup redis connection pool
INFO[0000] gateway/mqttpubsub: connecting to mqtt broker server=tcp://test.mosquitto.org:1883
INFO[0000] application/mqttpubsub: connecting to mqtt broker server=tcp://test.mosquitto.org:1883
INFO[0000] gateway/mqttpubsub: connected to mqtt server
INFO[0000] gateway/mqttpubsub: subscribing to rx topic topic=gateway/+/rx
INFO[0001] controller/mqttpubsub: connecting to mqtt broker server=tcp://localhost:1883
INFO[0001] application/mqttpubsub: connected to mqtt server
INFO[0001] application/mqttpubsub: subscribing to tx topic topic=application/+/node/+/tx
INFO[0001] applying database migrations
INFO[0001] controller/mqttpubsub: connected to mqtt broker
INFO[0001] controller/mqttpubsub: subscribing to tx topic topic=application/+/node/+/mac/tx
INFO[0001] migrations applied count=0
INFO[0001] registering json-rpc handler path=/rpc
INFO[0001] registering gui handler path=/
INFO[0001] starting http server bind=0.0.0.0:8000

when I use docker to run v0.8.0, i/o timeout. v0.7.0 is ok
$ docker run --rm -p 8000:8000 loraserver:0.8.0 loraserver --db-automigrate --net-id 010203 --band EU_863_870 --postgres-dsn "postgres://dbuser:[email protected]/loraserver?sslmode=disable" --redis-url "redis://192.168.10.11:6379" --gw-mqtt-server "tcp://test.mosquitto.org:1883" --app-mqtt-server "tcp://test.mosquitto.org:1883"
time="2016-07-04T00:26:07Z" level=info msg="starting LoRa Server" band="EU_863_870" net_id=010203 version=
time="2016-07-04T00:26:07Z" level=info msg="connecting to postgresql"
time="2016-07-04T00:26:07Z" level=info msg="setup redis connection pool"
time="2016-07-04T00:26:07Z" level=info msg="gateway/mqttpubsub: connecting to mqtt broker" server="tcp://test.mosquitto.org:1883"
time="2016-07-04T00:26:22Z" level=fatal msg="gateway-backend setup failed: gateway/mqttpubsub: connecting to broker failed: Network Error : dial tcp 85.119.83.194:1883: i/o timeout"

$ docker -v
Docker version 1.11.2, build b9f10c9

How to send data to the end nodes?

If it is possible, please include an example on how to send data (payload) to the end nodes. If I am not mistaken, currently there is no example for sending data only for receiving it. Thanks!

Which component is responsible for downlink duty-cycle management?

For uplink, I think it is the responsibility of the node that it does not exceed its duty-cycle (e.g. for the EU ISM band). Which component should be responsible for downlink? Is this the network server, or is it the responsibility of the gateway (packet_forwarder)?

Test of CN_470_510

1 Packets receive from nodes successfully as following log:

time="2016-07-18T15:32:19+08:00" level=info msg="starting http server" bind="0.0.0.0:8000"
time="2016-07-18T15:33:04+08:00" level=info msg="get apps length" get apps=1
time="2016-07-18T15:37:55+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:37:55+08:00" level=error msg="processing rx packet error: unknown MType: ConfirmedDataDown" data_base64="oEdH4QAKAgADUQcAYQNRBwBhzC9E7A=="
time="2016-07-18T15:39:29+08:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
time="2016-07-18T15:39:29+08:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
time="2016-07-18T15:39:29+08:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
time="2016-07-18T15:39:29+08:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
time="2016-07-18T15:39:29+08:00" level=info msg="application/mqttpubsub: connected to mqtt server"
time="2016-07-18T15:39:29+08:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
time="2016-07-18T15:43:51+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:43:51+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[3] CodeRate="4/5" Frequency=[472900000] LoRaSNR=[7.2] RFChain=[1] RSSI=[-114] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:43:48.684365 +0000 UTC]
time="2016-07-18T15:43:51+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"
time="2016-07-18T15:43:51+08:00" level=info msg="application/mqttpubsub: publishing rx payload" topic="application/0000000000000011/node/0000000000000007/rx" 
time="2016-07-18T15:43:51+08:00" level=info msg="node-session saved" dev_addr=00e14747
time="2016-07-18T15:45:45+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:45:45+08:00" level=error msg="processing rx packet error: unknown MType: ConfirmedDataDown" data_base64="oEdH4QAKAgADUQcAYQNRBwBhzC9E7A=="
time="2016-07-18T15:48:00+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:48:00+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[7] CodeRate="4/5" Frequency=[472100000] LoRaSNR=[7.2] RFChain=[0] RSSI=[-109] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:47:57.22486 +0000 UTC]
time="2016-07-18T15:48:00+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"
time="2016-07-18T15:48:00+08:00" level=info msg="application/mqttpubsub: publishing rx payload" topic="application/0000000000000011/node/0000000000000007/rx" 
time="2016-07-18T15:48:00+08:00" level=info msg="node-session saved" dev_addr=00e14747
time="2016-07-18T15:53:54+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:53:54+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[2] CodeRate="4/5" Frequency=[472700000] LoRaSNR=[8.8] RFChain=[1] RSSI=[-109] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:53:51.035185 +0000 UTC]
time="2016-07-18T15:53:54+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"

2 but some error occur says:
processing rx packet error: unknown MType: ConfirmedDataDown

I found it in internal/loraserver/loraserver.go:126, why not handle type "ConfirmedDataDown" ?

Deletion of node doesn't affect Redis DB

Looks like there's a bug in Delete method for Node.
When I press 'Delete' button the row is deleted from Postgres DB, but it stays in Redis DB.
So if you create a node with same DevEUI again all previous settings are back (but the data is not coming for the old settings and start coming only when you change DevAddr and keys).

FCntUp updated incorrectly

According to this specification (and I believe it is the latest), when you receive an uplink message, you update your FCntUp to match the FCnt, if its value seems correct. The server might have missed some messages, but if they are unconfirmed, that could be OK (if they are not too many).

At the receiver side, the corresponding counter is kept in sync with the value received provided the
value received has incremented compared to the current counter value and is less than the value
specified by MAX_FCNT_GAP 1 after considering counter rollovers.

In the code here, the counter FCntUp is directly incremented. Due to this, at a later time the following problems can occur:

Difference between observed and actual traffic getting bigger than MAX_FCNT_GAP and thus discarding possibly valid messages.
Fail to detect resending of a confirmed message. For example, if the device sends an unconfirmed message which is lost and a confirmed message which is received, but it's confirmation is lost, it will resend the packet. Due to the incorrect FCntUp, it will be impossible to detect that the message is already handled, but the confirmation was lost.

I am working on a pull request with a fix.

Support both RX1 and RX2

I'm planning to support both RX1 and RX2. This will be a config option on the node and node-session.

Hi, I setup Loraserver but when I try to visit the http page got nothing

./loraserver --net-id 010203 --band EU_863_870 --http-bind 0.0.0.0:8000 --postgres-dsn postgres://loraserver:dbpassword@localhost/loraserver?sslmode=disable --redis-url redis://localhost:6479 --db-automigrate
I start loraserver with the commend above from the precompiled binary file
All things seem work well according to log:
time="2016-07-12T14:30:10+08:00" level=info msg="starting LoRa Server" band="EU_863_870" net_id=010203 version=0.8.1
time="2016-07-12T14:30:10+08:00" level=info msg="connecting to postgresql"
time="2016-07-12T14:30:10+08:00" level=info msg="setup redis connection pool"
time="2016-07-12T14:30:10+08:00" level=info msg="gateway/mqttpubsub: connecting to mqtt broker" server="tcp://localhost:1883"
time="2016-07-12T14:30:10+08:00" level=info msg="application/mqttpubsub: connecting to mqtt broker" server="tcp://localhost:1883"
time="2016-07-12T14:30:10+08:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
time="2016-07-12T14:30:10+08:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
time="2016-07-12T14:30:10+08:00" level=info msg="controller/mqttpubsub: connecting to mqtt broker" server="tcp://localhost:1883"
time="2016-07-12T14:30:10+08:00" level=info msg="application/mqttpubsub: connected to mqtt server"
time="2016-07-12T14:30:10+08:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
time="2016-07-12T14:30:10+08:00" level=info msg="applying database migrations"
time="2016-07-12T14:30:10+08:00" level=info msg="controller/mqttpubsub: connected to mqtt broker"
time="2016-07-12T14:30:10+08:00" level=info msg="controller/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/mac/tx"
time="2016-07-12T14:30:10+08:00" level=info msg="migrations applied" count=0
time="2016-07-12T14:30:10+08:00" level=info msg="registering json-rpc handler" path="/rpc"
time="2016-07-12T14:30:10+08:00" level=info msg="registering gui handler" path="/"
time="2016-07-12T14:30:10+08:00" level=info msg="starting http server" bind="0.0.0.0:8001"

but when I visit http://ip:8001, I got a blank page(only with a title'LoRa Server'), anyone has suggestions?

Feature: Web interface and API authentication and authorization

Hi,
I think it will be helpful at some point of time to add some access control to the web API. As I am going to need that soonish, I have started looking into possible solutions. So far the use of JWT seems as a good option - easy to integrate, does not require too much shared knowledge if someone wants to run multiple loraservers, etc. Will you be willing to have such functionality and do you have any idea how you would want it to be implemented?

Hi, how to set the database from postgresql to mysql?

how to set the database from postgresql to mysql?
It seems that sqlx don't support mysql

Missing AppEUI check

There must be a check here to make sure the AppEUI from the node is the same as the AppEUI from the join-request: https://github.com/brocaar/loraserver/blob/master/internal/loraserver/join_request_accept.go#L24

ERR unknown command 'PEXPIRE'

HI, I'm getting an Error from what seems to be my gateway rx packet
output from loraserver.
INFO[0025] gateway/mqttpubsub: rx packet received
ERRO[0025] processing rx packet error: add rx packet to collect set error: ERR unknown command 'PEXPIRE' data_base64=...

the endnode also fails to join the network and reports a Join error

do we need to register the gateway with loraserver ?
Gateway is a Multitech Conduit
endnode is a Multitech mDot

Implement 433 MHz ISM Band for Rest of the World

This is a separate thread to request implementation for 433 MHz ISM Band for Rest of the World. Thanks

How to deploy lora-gateway-bridge and loraserver as a cluster

now for demo test, we deploy "lora-gateway-bridge" "loraserver" "mosquitto" "redis server" "PostgreSQL server" "http server" in one server or different server
But how to deploy a cluster network server maybe become a problem

(1) when two or more loraserver subscribe "gateway/+/rx" then message will be duplicate process.
(2) when two or more loraserver subscribe "application/+/node/+/tx" then message will be duplicate process or not?
(3) when two or more loraserver subscribe "application/+/node/+/mac/tx" then message will be duplicate process or not?

Cannot send TXpacket from server to im880a

Hi!
I am new to LoRaWAN, trying to setup my own network using iM880a + iC880 + RaspberryPi + loraserver.
And I managed to send sensor data from iM880 to the server then applications.
However, it seems like I cannot send any packet from applications to the server then gateway then iM880.

It stops here, I am not sure where the problem is.

Is anyone willing to help me?

Thank you so much!

Kevin

FCnt if node reset

Hi!
When the node reboot, i get not rx messages. How to avoid this issue? In the backend i have FCnt >0 (eg.50). When i reset it to 0, messages arrive. Should i manually change this or the backend can ignore it?
Thank you egain for this great software!

Please help testing AU 915-928 band

Same as #9 except that this issue is for the AU 915-928 ism band 😄

Pre-compiled binaries for testing can be found here:
https://www.dropbox.com/sh/ywg5v3469zct7i9/AABrkYi87ov-vIp1UC1e4CBWa?dl=0

Alternatively, you can build them from the au_915_928 branch with the following commands:

BANDS=au_915_928 GOOS=linux GOARCH=amd64 make package
BANDS=au_915_928 GOOS=linux GOARCH=386 make package
BANDS=au_915_928 GOOS=linux GOARCH=arm make package
BANDS=au_915_928 GOOS=darwin GOARCH=amd64 make package
BANDS=au_915_928 GOOS=windows BINEXT=.exe GOARCH=386 make package
BANDS=au_915_928 GOOS=windows BINEXT=.exe GOARCH=amd64 make package

support Class B

does the lora server support loraWAN class B? lora gateway from semtech support beacon mode. it would be cool that the lora server support Class B including align the beacon rx slot, send frame at the right rx slot.

Implement China 470-510 ISM band

How to add ISM band? eg.470-478?

Join accept delay

I think in join_request_accept.go I see that join-accept messages are loaded with the nodes RXDelay parameter (LoRa spec says 1s) where the node should probably use a separate JoinAcceptDelay parameter (LoRa spec says 5s) for the join accept.
Motes adhering to the LoRa spec fail to pickup the join-accept message if it's sent like a standard data packet at 1s.

Documentation link broken

It is still showed the old link, it should be changed to the new one: https://docs.loraserver.io

Devaddr got only 8bytes, wondering if it's enough

Devaddr got only 8bytes and each nodes need a unique Devaddr,
what if 8 bytes is not enough for all the nodes？

FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected

Аt startup I get the following error:
FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected

/etc/systemd/system/loraserver.service.d/loraserver.conf content:

[Service]
Environment="NET_ID=010203"
Environment="BAND=EU_863_870"
Environment="HTTP_BIND=0.0.0.0:8000"
Environment="POSTGRES_DSN=postgres://loraserver:dbpassword@localhost/loraserver$

Environment="DB_AUTOMIGRATE=True"

Host platform: Raspberry PI3

Please help testing US 902-928 ISM band

I'm looking for people who are up for testing the US 902-928 build of LoRa Server. All the work has been done, except that I'm unable to verify if it is really working 😉 (I don't have hardware to test with for this band).

Band specific configuration can be found in: https://github.com/brocaar/lorawan/tree/master/band

Same installation instructies apply (https://github.com/brocaar/loraserver/wiki/Getting-started), except that you need a loraserver binary for the US band. For testing, you can find pre-compiled binaries for the US band here: https://www.dropbox.com/sh/kar32nvpeynm33h/AAB1bz1qu9YYUMw6zqbgiDDua?dl=0

To build US band binaries yourself (from master):

BANDS=us_902_928 GOOS=linux GOARCH=amd64 make package
BANDS=us_902_928 GOOS=linux GOARCH=386 make package
BANDS=us_902_928 GOOS=linux GOARCH=arm make package
BANDS=us_902_928 GOOS=darwin GOARCH=amd64 make package
BANDS=us_902_928 GOOS=windows BINEXT=.exe GOARCH=386 make package
BANDS=us_902_928 GOOS=windows BINEXT=.exe GOARCH=amd64 make package

Cannot create new node because of DevEUI size check

Hi,

After installing new version (looks like this bug appeared about 7-10 days ago) I can't create a new node.
If I put a size of 8 byte in DevEUI it shows message 'exactly 16 bytes are expected', when I put 16 bytes in it it says 'exactly 8 bytes are expected'.

Also I suggest to exclude this check:
if ns.DevAddr.NwkID() != a.ctx.NetID.NwkID() {
return grpc.Errorf(codes.InvalidArgument, "DevAddr must contain NwkID %s", hex.EncodeToString([]byte{a.ctx.NetID.NwkID()}))
}
from file /internal/api/node_session.go because it is a usual situation when you buy a node with fixed DevAddr written on it and this check doesn't allow to add this node.

band config

Hi,
is the reference file band_au915_928.go is based on lorawan spec? I can't find the sec in the 1R0 spec.

The method to flush the unreceived data queue

Hi all,

I am wondering if there is a method to flush or shrink the un-received confirmed data queue.
While doing testing I echo heaps of data back to the end-nodes which based on the conditions they might not be received. Later on, when the issue is fixed, I receive heaps of old data buffered in the loraserver queue until I get to the bottom of the list and start receiving back, what I actually want to receive and I want some method of flushing that queue.

e.g.

end-node tx  ------------- server tx (echo back)
-----------------------------------------------------
   foo                     failed to echo back
   foo                     failed to echo back
   foo                     failed to echo back
   baz                           foo
   baz                           foo
   baz                           foo
   baz                           baz
   baz                           baz
   baz                           baz

Managing the downlink RX windows

Currently, the server sends scheduled downlink to both the RX1 and RX2 windows. However, it seems the correct way to do this is to only send on one particular RX window. The decision of which window to use is made by the server (if the end node does not get anything during RX1, it will wake up and listen again at RX2. However, if it gets a response at RX1, it would not wake up at RX2, so there is no need to downlink at both windows).

Before coming up with a rather complex scheme of deciding which RX window to use, I think it is OK to just hard-code the server to always use RX1.

A bit of digression: With the dumb Semtech packet forwarder, if the server tries to schedule downlink on both RX windows (which is what it's doing now), in effect only the RX2 packet will get through... The SX1301 (the concentrator chip on the gateway) only has a TX buffer of size 1. However, the packet forwarder will shove a TX packet into the 1301 even if the packet is scheduled to be sent 5 seconds later.... So if in the mean time a new downlink arrives before the previous one is sent out, the old one will just get overwritten... IMO, the packet forwarder should temporarily put the downlink packets into a queue sorted by departure time, and only shove the packet into the SX1301 if its departure time is imminent.

Need to delete Node Session when deleting Node

During the deletion of a Node (in internal/api/node.go) can you also delete the Node Session as well please. Leaving the Node Session causes data clashes later if the Node is recreated for a different App.

Maybe add the following after line 226 of internal/api/node.go

    return nil, grpc.Errorf(codes.Unauthenticated, "authentication failed: %s", err)
}

ns, err := storage.GetNodeSessionByDevEUI(a.ctx.RedisPool, eui)
if err != nil {

  return nil, grpc.Errorf(codes.Unknown, err.Error())

}

if err := storage.DeleteNodeSession(a.ctx.RedisPool, ns.DevAddr); err != nil {

  return nil, grpc.Errorf(codes.Unknown, err.Error())

}

if err := storage.DeleteNode(a.ctx.DB, a.ctx.RedisPool, eui); err != nil {
return nil, grpc.Errorf(codes.Unknown, err.Error())
}

Forming the correct "rxpk" and "txpk", Lora-Semtech-Bridge or LoraServer and the "rfch" to go for

At the moment When LoraServer forms a packet and sends it over MQTT, we see something like the message below before it hits the Lora-Semtech-Bridge.

{"txInfo":{"mac":"008000000000aaaa","immediately":false,"timestamp":1886440700,"frequency":925700000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5"},"phyPayload":"FFoo="}

Late on the bridge receives this and makes it like how LoRaWAN package should look like,

{"txpk":{"imme":false,"tmst":1886440700,"freq":925.7,"rfch":1,"powe":20,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":17,"data":"ffOO"}}

One idea could be that in the long run, just to map the values to the correct format on the LoraServer dependent on the chip we are sending it to (in this case Semtech).

And also some information such as the rfch value is never been assigned through the code so it gets defaulted to zero on txpk. This limits the gateways e.g. with only Radio 1 enabled (set in the packet forwarder) cuz the txpks sent over rfch 1 will be replied on rfch 0 rather than 1.

So I was thinking in the normal situation which the hybrid gateway is using it's both rfchs (both SX1257 s), why not to actually alternate the rfch on the txpk at the LoraServer to share the load between two SX1257s rather than hammering one all the time.

This also could potentially prevent the packages to be overwritten on SX1301 until they move the experimental-Just-in-Time-Queue implementation of Semtech Packet Forwarder to the master branch and release it.

(Meanwhile, the easy solution) would to read the rfch value from rxpk and assign it to the same key on rxpk rather than letting it getting defaulted. 🙌

Decoupling "inventory" from LoRa Server (looking for feedback)

I'm thinking about decoupling the "inventory" part from LoRa Server. I think this makes the whole setup more flexible, as it allows you to use a different data storage, data schema etc, different transports between the lora-app-server and the application receiving (and sending) payloads. Below a draft diagram:

This means that the Application / Node and Channel(List) APIs will be moved to the new lora-app-server, and that loraserver only has knowledge about a node-session.

My idea is to keep the RESTful and gRPC api with (optional) JWT auth in lora-app-server, all other gRPC interfaces will be (optional) client side certificate auth only as they should not be exposed to the outer world directly. Of course this means there will be some breaking changes, but I think apart from moving the API from one service to the other, we can limit the impact.

Looking forward to feedback and thoughts.

China 779-787 ISM band

I'm planning to implement support for the 779-787 ISM band soon. Please let me know if you would be able to help out with testing (I will provide custom binaries for this range), as I don't have hardware myself for this frequency range.

Time of message send

Most likely is me missing something.

However the payload from the topic application/[AppEUI]/node/[DevEUI]/rx which is the one containing the data from the motes does not contains any reference to the time when the message has been sent.

How do I know when a particular messages is been sent?

Make FRMPayload decryption optional

According to the spec (section 4.3.3.2), it should be possible to perform encryption on upper layers. In this case the network server should not try to decrypt the information.

I am working on this right now. Currently I do not intend to support encryption preference for every possible port number as it seems required by the spec. For each device it will be possible to have the server either decrypt the payload or leave it as it is - the same behavior for all fport numbers other > 0 (obviously the default behavior will not change).

How does this sound to you?

confirmation not received

Hello!

First of all thank you for you efforts for building up the lora server. Everything easy to use and have a great documentation.

I have a iC880A + Rasp Pi 3 gateway with Microchip LoRa Mote (RN2483). I using the Semtech lora packet forwarder (lora_pkt_fwd) with your gateway_bridge and server. The gateway and the endpoint are few centimeter away from each other.

I have a problem with the confirmed messages + OTAA joining (I think its the same problem). Most of the time when I send a confirmed message I can see my packet arrived successfully (CRC_OK) but after that the server do not send back a confirm message so I got a mac_err as respond from the RN2483. I got a confirmed message about every 8th attempt. I think it is the same with OTAA my packets arrived, but the server do not respond to them and I can join about every 6th attempt.

Sometimes I got 2, 3 confirmation from the server in row (very rarely).

I couldn't see any interesting log info in the server log. Seems like my packet is never arrived there. Do you have any idea whats going wrong?

Question: Implementation of mac commands

Hi Orne,

Yesterday I started looking into the MAC commands and here is how I imagine them to work (let me know if that seems OK to you).

LinkCheckReq/LinkCheckAns is somewhat clear (I think that we take lsnr or 0 if lsnr is negative and the number of times the packet was received and construct the answer).
The other MAC commands should be sent by the users (in my opinion through the web interface). It sounds somewhat OK for me if only one set of MAC commands can be saved per device. I would expect that the MAC commands would be more important than the user data if we have to choose between the two (although that might be configurable) as they are supposed to optimize the performance of the end device. I would also expect that in the MAC commands set there are only commands with unique CID. The reason for this assumption is that I did not see any requirement for the order of the MAC commands' answers and if this is the case, then having multiple times the same CID would lead to ambiguous answers. Generally it seems reasonable to be able to send multiple NewChannelReq, but I guess it is not that crucial. The user will be able to see the answers to the last set of MAC commands through the web interface.

I have already implemented the part for LinkCheckReq/LinkCheckAns (as described above), but I was not able to test it today, so ~~I will test it tomorrow~~ I will test it as soon as my end device recovers from whatever happened to it and push it to my fork. Depending on our discussion I can implement the rest as well and make a pull request.

What do you think about all that?

Thanks,
Ivaylo Petrov

MQTT connection issues

After running loraserver for a long time (I'm using the latest https://github.com/eclipse/paho.mqtt.golang version: 4ab3e86, but the problem is not exclusive to this version), it runs into mqtt connection issues. Most of the time, it is able to recover by (automatically) reconnecting and re-subscribing, but sometimes it looses the connection with the mqtt server (Mosquitto 1.4.3 in my case) and stops handling packets. Server is a Digitalocean Ubuntu 15.10 server. I see the same behaviour for the semtech bridge.

One part where the mqtt connection happens is: https://github.com/brocaar/loraserver/blob/master/application/mqttpubsub/backend.go

This problem might be related to eclipse/paho.mqtt.golang#32

Please share your findings!

loraserver logs:

Apr 01 18:10:08 iot loraserver[18659]: time="2016-04-01T18:10:08-04:00" level=info msg="application/mqttpubsub: publishing message" topic="application/0101010101010101/node/0202020202020202/rx"
Apr 01 18:10:08 iot loraserver[18659]: time="2016-04-01T18:10:08-04:00" level=info msg="node-session saved" dev_addr=07e4ac98
Apr 01 18:10:58 iot loraserver[18659]: time="2016-04-01T18:10:58-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:10:58 iot loraserver[18659]: time="2016-04-01T18:10:58-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 18:10:58 iot loraserver[18659]: time="2016-04-01T18:10:58-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 18:11:08 iot loraserver[18659]: time="2016-04-01T18:11:08-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:11:08 iot loraserver[18659]: time="2016-04-01T18:11:08-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 18:11:08 iot loraserver[18659]: time="2016-04-01T18:11:08-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 18:11:10 iot loraserver[18659]: time="2016-04-01T18:11:10-04:00" level=info msg="packet(s) collected" gw_count=1 gw_macs=1dee08d0b691d149 mtype=UnconfirmedDataUp
Apr 01 18:11:10 iot loraserver[18659]: time="2016-04-01T18:11:10-04:00" level=info msg="application/mqttpubsub: publishing message" topic="application/0101010101010101/node/0202020202020202/rx"
Apr 01 18:11:10 iot loraserver[18659]: time="2016-04-01T18:11:10-04:00" level=info msg="node-session saved" dev_addr=07e4ac98
Apr 01 18:12:12 iot loraserver[18659]: time="2016-04-01T18:12:12-04:00" level=info msg="packet(s) collected" gw_count=1 gw_macs=1dee08d0b691d149 mtype=UnconfirmedDataUp
Apr 01 18:12:12 iot loraserver[18659]: time="2016-04-01T18:12:12-04:00" level=info msg="application/mqttpubsub: publishing message" topic="application/0101010101010101/node/0202020202020202/rx"
Apr 01 18:12:12 iot loraserver[18659]: time="2016-04-01T18:12:12-04:00" level=info msg="node-session saved" dev_addr=07e4ac98
Apr 01 18:13:15 iot loraserver[18659]: time="2016-04-01T18:13:15-04:00" level=info msg="packet(s) collected" gw_count=1 gw_macs=1dee08d0b691d149 mtype=UnconfirmedDataUp
Apr 01 18:13:15 iot loraserver[18659]: time="2016-04-01T18:13:15-04:00" level=info msg="application/mqttpubsub: publishing message" topic="application/0101010101010101/node/0202020202020202/rx"
Apr 01 18:13:15 iot loraserver[18659]: time="2016-04-01T18:13:15-04:00" level=info msg="node-session saved" dev_addr=07e4ac98
Apr 01 18:14:17 iot loraserver[18659]: time="2016-04-01T18:14:17-04:00" level=info msg="packet(s) collected" gw_count=1 gw_macs=1dee08d0b691d149 mtype=UnconfirmedDataUp
Apr 01 18:14:17 iot loraserver[18659]: time="2016-04-01T18:14:17-04:00" level=info msg="application/mqttpubsub: publishing message" topic="application/0101010101010101/node/0202020202020202/rx"
Apr 01 18:14:17 iot loraserver[18659]: time="2016-04-01T18:14:17-04:00" level=info msg="node-session saved" dev_addr=07e4ac98
Apr 01 18:21:27 iot loraserver[18659]: time="2016-04-01T18:21:27-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:21:27 iot loraserver[18659]: time="2016-04-01T18:21:27-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 18:21:27 iot loraserver[18659]: time="2016-04-01T18:21:27-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 18:21:37 iot loraserver[18659]: time="2016-04-01T18:21:37-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:21:37 iot loraserver[18659]: time="2016-04-01T18:21:37-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 18:21:37 iot loraserver[18659]: time="2016-04-01T18:21:37-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 18:50:04 iot loraserver[18659]: time="2016-04-01T18:50:04-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:50:04 iot loraserver[18659]: time="2016-04-01T18:50:04-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 18:50:04 iot loraserver[18659]: time="2016-04-01T18:50:04-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 18:50:14 iot loraserver[18659]: time="2016-04-01T18:50:14-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 18:50:14 iot loraserver[18659]: time="2016-04-01T18:50:14-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 18:50:14 iot loraserver[18659]: time="2016-04-01T18:50:14-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 19:16:44 iot loraserver[18659]: time="2016-04-01T19:16:44-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 19:16:44 iot loraserver[18659]: time="2016-04-01T19:16:44-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 19:16:44 iot loraserver[18659]: time="2016-04-01T19:16:44-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 19:16:54 iot loraserver[18659]: time="2016-04-01T19:16:54-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 19:16:54 iot loraserver[18659]: time="2016-04-01T19:16:54-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 19:16:54 iot loraserver[18659]: time="2016-04-01T19:16:54-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 20:04:24 iot loraserver[18659]: time="2016-04-01T20:04:24-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:04:24 iot loraserver[18659]: time="2016-04-01T20:04:24-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 20:04:24 iot loraserver[18659]: time="2016-04-01T20:04:24-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 20:04:34 iot loraserver[18659]: time="2016-04-01T20:04:34-04:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:04:34 iot loraserver[18659]: time="2016-04-01T20:04:34-04:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
Apr 01 20:04:34 iot loraserver[18659]: time="2016-04-01T20:04:34-04:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
Apr 01 20:34:48 iot loraserver[18659]: time="2016-04-01T20:34:48-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:34:48 iot loraserver[18659]: time="2016-04-01T20:34:48-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 20:34:48 iot loraserver[18659]: time="2016-04-01T20:34:48-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 20:34:58 iot loraserver[18659]: time="2016-04-01T20:34:58-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:34:58 iot loraserver[18659]: time="2016-04-01T20:34:58-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 20:34:58 iot loraserver[18659]: time="2016-04-01T20:34:58-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 20:59:08 iot loraserver[18659]: time="2016-04-01T20:59:08-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:59:08 iot loraserver[18659]: time="2016-04-01T20:59:08-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 20:59:08 iot loraserver[18659]: time="2016-04-01T20:59:08-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 20:59:18 iot loraserver[18659]: time="2016-04-01T20:59:18-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
Apr 01 20:59:18 iot loraserver[18659]: time="2016-04-01T20:59:18-04:00" level=info msg="application/mqttpubsub: connected to mqtt server"
Apr 01 20:59:18 iot loraserver[18659]: time="2016-04-01T20:59:18-04:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
Apr 01 21:13:18 iot loraserver[18659]: time="2016-04-01T21:13:18-04:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
...

Mosquitto logs:

1459546993: Socket error on client 885a5fc6-12cb-4249-a7c4-9cb4aaf99d10, disconnecting.
1459546993: New client connected from 127.0.0.1 as c371d40c-876d-4cf1-a900-24539741f56b (c1, k30).
1459547003: Socket error on client c371d40c-876d-4cf1-a900-24539741f56b, disconnecting.
1459547003: New connection from 127.0.0.1 on port 1883.
1459547003: New client connected from 127.0.0.1 as 43e07938-154a-4571-9e14-bb4443cf5138 (c1, k30).
1459547103: New connection from 127.0.0.1 on port 1883.
1459547103: Socket error on client 43e07938-154a-4571-9e14-bb4443cf5138, disconnecting.
1459547103: New client connected from 127.0.0.1 as 518e58fe-f2e5-49ce-b621-cae192e184cc (c1, k30).
1459547113: Socket error on client 518e58fe-f2e5-49ce-b621-cae192e184cc, disconnecting.
1459547113: New connection from 127.0.0.1 on port 1883.
1459547113: New client connected from 127.0.0.1 as 2e11c696-b3c2-436e-82d0-4e20952f5acf (c1, k30).
1459547963: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1459548105: Socket error on client 534e8be8-8dbb-4c05-b29d-ae8d13b9a979, disconnecting.
1459548105: New connection from 127.0.0.1 on port 1883.
1459548105: New client connected from 127.0.0.1 as 8664a25e-22e5-4417-89ef-b862e33e2c90 (c1, k30).
1459548115: Socket error on client 8664a25e-22e5-4417-89ef-b862e33e2c90, disconnecting.
1459548115: New connection from 127.0.0.1 on port 1883.
1459548115: New client connected from 127.0.0.1 as 398a4f2e-4b18-4148-a322-176249184796 (c1, k30).
1459548479: New connection from 127.0.0.1 on port 1883.
1459548479: Socket error on client 12220090-cb15-4ba5-9636-b98dc04a1796, disconnecting.
1459548479: New client connected from 127.0.0.1 as 16c9079e-6ef7-4097-81d3-66f517c48ff6 (c1, k30).
1459548489: Socket error on client 16c9079e-6ef7-4097-81d3-66f517c48ff6, disconnecting.
1459548489: New connection from 127.0.0.1 on port 1883.
1459548489: New client connected from 127.0.0.1 as fcc78d39-2fd3-4a17-980a-73d8b290989f (c1, k30).
1459548658: Socket error on client 398a4f2e-4b18-4148-a322-176249184796, disconnecting.
1459548658: New connection from 127.0.0.1 on port 1883.
1459548658: New client connected from 127.0.0.1 as 1a30a813-adaa-4fb6-8581-3be188c482f5 (c1, k30).
1459548668: Socket error on client 1a30a813-adaa-4fb6-8581-3be188c482f5, disconnecting.
1459548668: New connection from 127.0.0.1 on port 1883.
1459548668: New client connected from 127.0.0.1 as 73f2fd18-c10d-4b09-a9e1-c99d293f8e34 (c1, k30).
1459549287: Socket error on client 73f2fd18-c10d-4b09-a9e1-c99d293f8e34, disconnecting.
1459549287: New connection from 127.0.0.1 on port 1883.
1459549287: New client connected from 127.0.0.1 as f7a011f3-a9a0-4e64-98ad-1850233ddbaf (c1, k30).
1459549297: Socket error on client f7a011f3-a9a0-4e64-98ad-1850233ddbaf, disconnecting.
1459549297: New connection from 127.0.0.1 on port 1883.
1459549297: New client connected from 127.0.0.1 as 314ef86a-9fdb-4ce1-92a6-6d2844a38567 (c1, k30).
...

could not setup mqtt backend: Identifier rejected

is there a way to set the Client ID ?
We're connecting it to VerneMQ and getting the "Identifier rejected" response to a join for both loraserver and lora-gateway-bridge when we have password authentication on the broker

I'm not sure if our sever is not configured properly or the client connect is different from what it expects and mosquitto is ok with it

When we enable anonymous mode on our broker we can connect succesfully ( but this seems to negate the username password security )
We get this debug message from the broker when lora_gateway_bridge connects :

[warning] <0.322.0>@vmq_mqtt_fsm:check_user:517 can't authenticate client {[],<<"anon-26oFeDnEZJWAhf3mewMbcTdnzG8=">>}

Multiple end-nodes join issue

Hi guys,

After whole lot of wrestling with bits and peices of LoRa today I was trying to connect a 2nd end-node to LoraServer, and surprisingly, when I have one end-node already joined, the 2nd one refuses to join.

I have tested them with the Loraserver which comes with Multitech AEP Conduit and they connected fine, so in this instance either Multitech mDot end-node library and Multitech Conduit gateway both have the same bug which enables me to connect multiple end-nodes or something isn't set up in the brocaar/loraserver right.

Tomorrow I am going to try flashing the Multitech mDots with Semtech open source LoraWAN firmware to see if I'll have the same issue but meanwhile I thought, I'll ask this and you'll get it see it tonight.

atm, on the Loraserver GUI I have set up a single Application (0000000000000001) and my end-nodes have two different Appkeys (00000000000000000000000000000001 and 00000000000000000000000000000002) and each one individually connects to the server alright but not together.

let me now what you think about this,

Cheers

Mehrad

Why I modified the static folder(index.html), but after recompile no change?

Why I modified the static folder(index.html), but after recompile no change?
Do I need to use tool 'go-bindata' to regenerate static pkg？

Loraserver failed to start?

Hi! Per your instructions I installed the loraserver version 0.10.0 on my Pi B running Ubuntu 16.04 LTS. When I go to launch the service with sudo systemctl start loraserver, the logs show:

Failed to start loraserver.

When I look at the syslog I see "loraserver.service: failed at step EXEC spawning /usr/local/bin/loraserver: Exec format error

Not sure if this is a bug or user error. Most likely the latter...

ADR support

After the authentication / authorization for the API, I'm planning to look into ADR support. Looking forward to feedback on this, especially regarding the logic which triggers the network to request a data-rate adaption. Please share your thoughts!

I want to store the uplink-data into Postgresql，where is the proper location to put my code

Is it in func handleCollectedDataUpPackets() ?
Good news is that it seems the PHYPayload decrypt already done.
Anyone already do this job?

DevAddr problem on Rx

In my test setup, I have couple of nodes sending payload to the server. There is no problem with joining, however one of the nodes's DevAddr seems to be read incorrectly:

INFO[2753] gateway: sending udp packet to gateway addr=x.x.x.x54847 type=PushACK
INFO[2754] gateway: received udp packet from gateway addr=y.y.y.y:56394 type=PushData
INFO[2754] gateway: rxpk packet received addr=y.y.y.y:56394 data=QEFBMxwAAAACzhgt2HnzjwnH0GAuqqhyCOC0g1QR2mCVyR5Lfo6AhQ== mac=0080000000009zzz
INFO[2754] backend/mqttpubsub: publishing packet topic=gateway/0080000000009bbb/rx
INFO[2754] gateway: sending udp packet to gateway addr=y.y.y.y:56394 type=PushACK
INFO[2754] gateway/mqttpubsub: rx packet received
ERRO[2754] processing rx packet error: get node-session for DevAddr 1c334141 error: redigo: nil returned data_base64=QEFBMxwAAAACzhgt2HnzjwnH0GAuqqhyCOC0g1QR2mCVyR5Lfo6AhQ==

Under Session/ABP in the server I can see different DevAddr associated with that node (630e8d31) and the packet counter obviously doesn't increment

Idle State! Is there such a thing in loraserver/semtech-bridge?

Hey guys,

This morning, after I came back to my setup, I have notice that my server is inactive and since I was already tailing the logs I had a quick look and fair enough the last message on the Semtech-Bridge logs was,

level=info msg="backend/mqttpubsub: unsubscribing from topic" topic="gateway/0000024b000e0000/tx"

I have disabled all the testing end-nodes before I left, last night, so nothing was transmitting but I am wondering, if there is such a situation, would the server go to some sort of Idle State and snooze? And if so, how would you wake it up?

I have poked my gateway by restarting it's packet forwarder and the stream started flowing again but surely this can't be the solution.

I will do another follow up test tonight and report tomorrow,