Gateway bridge could not receive from loraserver

ChirpStack Gateway Bridge
1

I have a LoraWAN node and a gateway on hand, and have installed the latest gateway bridge, lora server, app server all on one machine(Ubuntu14.04). During OTAA, I could see join-request was successfully handled and something (maybe join-accept) was sent out by loraserver, yet nothing was showed on the gateway bridge log. It seemed gateway bridge could not receive messages from loraserver, does anyone have a clue, or a way to debug this issue?

logs from gateway bridge(tail -f /var/log/lora-gateway-bridge/lora-gateway-bridge.log):
time=“2017-12-15T18:25:15+08:00” level=info msg=“gateway: received udp packet from gateway” addr=10.0.10.31:1929 protocol_version=1 type=PushData
time=“2017-12-15T18:25:15+08:00” level=info msg=“gateway: rxpk packet received” addr=10.0.10.31:1929 data=“AAEBAQEBAQEBAQEBAQEBAQEJANZ7UUI=” mac=0102030405060708
time=“2017-12-15T18:25:15+08:00” level=info msg=“backend: publishing packet” topic=“gateway/0102030405060708/rx”
time=“2017-12-15T18:25:15+08:00” level=info msg=“gateway: sending udp packet to gateway” addr=10.0.10.31:1929 protocol_version=1 type=PushACK

logs from loraserver(tail -f /var/log/loraserver/loraserver.log):
time=“2017-12-15T18:25:15+08:00” level=info msg=“backend/gateway: rx packet received”
time=“2017-12-15T18:25:15+08:00” level=info msg=“packet(s) collected” dev_eui=0101010101010101 gw_count=1 gw_macs=0102030405060708 mtype=JoinRequest
time=“2017-12-15T18:25:15+08:00” level=info msg=“device-session saved” dev_addr=0743c73d dev_eui=0101010101010101
time=“2017-12-15T18:25:15+08:00” level=info msg=“device-activation created” dev_eui=0101010101010101 id=8
time=“2017-12-15T18:25:15+08:00” level=info msg=“backend/gateway: publishing tx packet” topic=“gateway/0102030405060708/tx”

logs from mqtt(mosquitto_sub -v -t “#” -h localhost -p 1883):
gateway/0102030405060708/rx {“rxInfo”:{“mac”:“0102030405060708”,“time”:“2017-12-14T16:21:17.528002Z”,“timestamp”:3512348611,“frequency”:914900000,“channel”:63,“rfChain”:63,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-35,“loRaSNR”:5.1,“size”:23,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:9,“bandwidth”:125}},“phyPayload”:“AAEBAQEBAQEBAQEBAQEBAQEJANZ7UUI=”}
application/1/node/0101010101010101/join {“applicationID”:“1”,“applicationName”:“application”,“deviceName”:“ping”,“devEUI”:“0101010101010101”,“devAddr”:“0743c73d”}
gateway/0102030405060708/tx {“txInfo”:{“mac”:“0102030405060708”,“immediately”:false,“timestamp”:3517348611,“frequency”:927500000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:9,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:null},“phyPayload”:“IIUAS9iWu+EQ/suEUos5ctc=”}

2

The fact that the above messages shows up as MQTT message, it means that LoRa Server did send a downlink frame for transmission, so the issue is between the MQTT broker (Mosquitto) and LoRa Gateway Bridge.

When you started LoRa Gateway Bridge and it received the first PullData, did you see the message backend: subscribing to topic? Example log:

INFO[0000] starting LoRa Gateway Bridge                  docs="https://docs.loraserver.io/lora-gateway-bridge/" version=2.2.0
INFO[0000] backend: connecting to mqtt broker            server="tcp://127.0.0.1:1883"
INFO[0000] backend: connected to mqtt broker
INFO[0000] gateway: starting gateway udp listener        addr=0.0.0.0:1700
INFO[0004] gateway: received udp packet from gateway     addr=192.168.1.241:48541 protocol_version=2 type=PullData
INFO[0004] backend: subscribing to topic                 topic="gateway/00800000a00016b6/tx"
INFO[0004] gateway: sending udp packet to gateway        addr=192.168.1.241:48541 protocol_version=2 type=PullACK
3

Thanks for your quik reply.
No, I did not see any subscribing log in bridge. I could see only subscribing to rx and stats log in loraserver, while nothing subscribe to tx. In the log of lora-app-server, there was one as “msg=“handler/mqtt: subscribling to tx topic” topic=“application/+/node/+/tx”” The whole log is listed at last.
I installed the bridge and loraserver with command “apt-get install xxx”, and changed little on the configuration files, which are both listed below.

logs from gateway bridge(/var/log/lora-gateway-bridge/lora-gateway-bridge.log):
time=“2017-12-18T14:07:54+08:00” level=info msg=“starting LoRa Gateway Bridge” docs=“https://docs.loraserver.io/lora-gateway-bridge/” version=2.1.5
time=“2017-12-18T14:07:54+08:00” level=info msg=“backend: connecting to mqtt broker” server=“tcp://127.0.0.1:1883”
time=“2017-12-18T14:07:54+08:00” level=info msg=“gateway: starting gateway udp listener” addr=0.0.0.0:1700
time=“2017-12-18T14:07:54+08:00” level=info msg=“backend: connected to mqtt broker”
time=“2017-12-18T14:10:38+08:00” level=info msg=“gateway: received udp packet from gateway” addr=10.0.10.31:1929 protocol_version=1 type=PushData
time=“2017-12-18T14:10:38+08:00” level=info msg=“gateway: rxpk packet received” addr=10.0.10.31:1929 data=“AAEBAQEBAQEBAQEBAQEBAQEVAFlgX9s=” mac=0102030405060708
time=“2017-12-18T14:10:38+08:00” level=info msg=“backend: publishing packet” topic=“gateway/0102030405060708/rx”
time=“2017-12-18T14:10:38+08:00” level=info msg=“gateway: sending udp packet to gateway” addr=10.0.10.31:1929 protocol_version=1 type=PushACK

logs from loraserver(/var/log/loraserver/loraserver.log):
time=“2017-12-18T14:08:16+08:00” level=info msg=“starting LoRa Server” band=“US_902_928” docs=“https://docs.loraserver.io/” net_id=010203 version=0.22.1
time=“2017-12-18T14:08:16+08:00” level=info msg=“setup redis connection pool” url=“redis://localhost:6379”
time=“2017-12-18T14:08:16+08:00” level=info msg=“connecting to postgresql”
time=“2017-12-18T14:08:16+08:00” level=info msg=“backend/gateway: connecting to mqtt broker” server=“tcp://localhost:1883”
time=“2017-12-18T14:08:16+08:00” level=info msg=“setup application-server client pool” ca_cert= tls_cert= tls_key=
time=“2017-12-18T14:08:16+08:00” level=info msg=“configuring join-server” ca_cert= server=“http://localhost:8003” tls_cert= tls_key=
time=“2017-12-18T14:08:16+08:00” level=info msg=“no network-controller configured”
time=“2017-12-18T14:08:16+08:00” level=info msg=“applying database migrations”
time=“2017-12-18T14:08:17+08:00” level=info msg=“backend/gateway: connected to mqtt server”
time=“2017-12-18T14:08:17+08:00” level=info msg=“backend/gateway: subscribing to rx topic” topic=“gateway/+/rx”
time=“2017-12-18T14:08:17+08:00” level=info msg=“backend/gateway: subscribing to stats topic” topic=“gateway/+/stats”
time=“2017-12-18T14:08:17+08:00” level=info msg=“migrations applied” count=0
time=“2017-12-18T14:08:17+08:00” level=info msg=“starting api server” bind=“0.0.0.0:8000” ca-cert= tls-cert= tls-key=
time=“2017-12-18T14:08:17+08:00” level=info msg=“starting gateway api server” bind=“0.0.0.0:8002” ca-cert= tls-cert= tls-key=
time=“2017-12-18T14:10:38+08:00” level=info msg=“backend/gateway: rx packet received”
time=“2017-12-18T14:10:38+08:00” level=info msg=“packet(s) collected” dev_eui=0101010101010101 gw_count=1 gw_macs=0102030405060708 mtype=JoinRequest
time=“2017-12-18T14:10:39+08:00” level=info msg=“device-session saved” dev_addr=07cd3e0b dev_eui=0101010101010101
time=“2017-12-18T14:10:39+08:00” level=info msg=“device-activation created” dev_eui=0101010101010101 id=9
time=“2017-12-18T14:10:39+08:00” level=info msg=“backend/gateway: publishing tx packet” topic=“gateway/0102030405060708/tx”

logs from lora-app-server(/var/log/lora-app-server/lora-app-server.log):
time=“2017-12-18T14:08:57+08:00” level=info msg=“starting LoRa App Server” docs=“https://docs.loraserver.io/” version=0.14.2
time=“2017-12-18T14:08:57+08:00” level=info msg=“connecting to postgresql”
time=“2017-12-18T14:08:57+08:00” level=info msg=“setup redis connection pool”
time=“2017-12-18T14:08:57+08:00” level=info msg=“handler/mqtt: connecting to mqtt broker” server=“tcp://localhost:1883”
time=“2017-12-18T14:08:57+08:00” level=info msg=“applying database migrations”
time=“2017-12-18T14:08:57+08:00” level=info msg=“handler/mqtt: connected to mqtt broker”
time=“2017-12-18T14:08:57+08:00” level=info msg=“migrations applied” count=0
time=“2017-12-18T14:08:57+08:00” level=info msg=“starting application-server api” bind=“0.0.0.0:8001” ca-cert= tls-cert= tls-key=
time=“2017-12-18T14:08:57+08:00” level=info msg=“starting join-server api” bind=“0.0.0.0:8003” ca_cert= tls_cert= tls_key=
time=“2017-12-18T14:08:57+08:00” level=info msg=“starting client api server” bind=“0.0.0.0:8080” tls-cert="/etc/lora-app-server/certs/http.pem" tls-key="/etc/lora-app-server/certs/http-key.pem"
time=“2017-12-18T14:08:57+08:00” level=info msg=“handler/mqtt: subscribling to tx topic” topic=“application/+/node/+/tx”
time=“2017-12-18T14:08:57+08:00” level=info msg=“registering rest api handler and documentation endpoint” path="/api"
time=“2017-12-18T14:10:39+08:00” level=info msg=“js: request received” message_type=JoinReq receiver_id=0101010101010101 sender_id=010203 transaction_id=2442546319
time=“2017-12-18T14:10:39+08:00” level=info msg=“device-keys updated” dev_eui=0101010101010101
time=“2017-12-18T14:10:39+08:00” level=info msg=“device-activation created” dev_eui=0101010101010101 id=11
time=“2017-12-18T14:10:39+08:00” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/0101010101010101/join”
time=“2017-12-18T14:10:39+08:00” level=info msg=“js: sending response” message_type=JoinAns receiver_id=010203 result_code=Success sender_id=0101010101010101 transaction_id=2442546319

configuration file for lora-gateway-bridge:
###ip:port to bind the UDP listener to (default: “0.0.0.0:1700”)
UDP_BIND=0.0.0.0:1700

###mqtt server (e.g. scheme://host:port where scheme is tcp, ssl or ws) (default: “tcp://127.0.0.1:1883”)
MQTT_SERVER=tcp://127.0.0.1:1883

###mqtt server username (optional)
MQTT_USERNAME=

###mqtt server password (optional)
MQTT_PASSWORD=

###debug=5, info=4, warning=3, error=2, fatal=1, panic=0 (default: 4)
LOG_LEVEL=5

###skip the CRC status-check of received packets
SKIP_CRC_CHECK=true

configuration file for loraserver:
###network identifier (NetID, 3 bytes) encoded as HEX (e.g. 010203)
NET_ID=010203

###ism band configuration to use (options: AU_915_928, CN_470_510, EU_863_870, US_902_928)
BAND=US_902_928

###ca certificate used by the api server (optional)
CA_CERT=

###tls certificate used by the api server (optional)
TLS_CERT=

###tls key used by the api server (optional)
TLS_KEY=

###ip:port to bind the api server (default: “0.0.0.0:8000”)
BIND=0.0.0.0:8000

###redis url (e.g. redis://user:password@hostname:port/0) (default: “redis://localhost:6379”)
REDIS_URL=redis://localhost:6379

###postgresql dsn (e.g.: postgres://user:password@hostname/database?sslmode=disable)
#POSTGRES_DSN=postgres://localhost/loraserver?sslmode=disable
POSTGRES_DSN=postgres://loraserver_ns:dbpassword@localhost/loraserver_ns?sslmode=disable

###automatically apply database migrations
DB_AUTOMIGRATE=true

###mqtt broker server used by the gateway backend (e.g. scheme://host:port where scheme is tcp, ssl or ws) (default: “tcp://localhost:1883”)
GW_MQTT_SERVER=tcp://localhost:1883

###mqtt username used by the gateway backend (optional)
GW_MQTT_USERNAME=

###mqtt password used by the gateway backend (optional)
GW_MQTT_PASSWORD=

###ca certificate used by the application-server client (optional)
AS_CA_CERT=

###tls certificate used by the application-server client (optional)
AS_TLS_CERT=

###tls key used by the application-server client (optional)
AS_TLS_KEY=

###hostname:port of the network-controller api server (optional)
NC_SERVER=

###ca certificate used by the network-controller client (optional)
NC_CA_CERT=

###tls certificate used by the network-controller client (optional)
NC_TLS_CERT=

###tls key used by the network-controller client (optional)
NC_TLS_KEY=

###time to wait for uplink de-duplication (default: 200ms)
DEDUPLICATION_DELAY=200ms

###delay between uplink delivery to the app server and getting the downlink data from the app server (if any) (default: 100ms)
GET_DOWNLINK_DATA_DELAY=100ms

###timezone to use when aggregating data (e.g. ‘Europe/Amsterdam’) (optional, by default the local timezone is used)
###TIMEZONE=Europe/Amsterdam

###create non-existing gateways on receiving of stats
GW_CREATE_ON_STATS=true

###aggregation intervals to use for aggregating the gateway stats (valid options: second, minute, hour, day, week, month, quarter, year)
GW_STATS_AGGREGATION_INTERVALS=minute,hour,day

###extra frequencies to use for ISM bands that implement the CFList
###EXTRA_FREQUENCIES=867100000,867300000,867500000,867700000

###enable only a given sub-set of channels (e.g. ‘0-7,64’)
###ENABLE_UPLINK_CHANNELS=0-7,64

###the ttl after which a node-session expires after no activity (default 31 days)
NODE_SESSION_TTL=744h0m0s

###log uplink and downlink frames to the database
LOG_NODE_FRAMES=true

###ca certificate used by the gateway api server (optional)
GW_SERVER_CA_CERT=

###tls certificate used by the gateway api server (optional)
GW_SERVER_TLS_CERT=

###tls key used by the gateway api server (optional)
GW_SERVER_TLS_KEY=

###JWT secret used by the gateway api server for gateway authentication / authorization
###You could generate this by executing ‘openssl rand -base64 32’ for example
GW_SERVER_JWT_SECRET=verysecret

###ip:port to bind the gateway api server (default: “0.0.0.0:8002”)
GW_SERVER_BIND=0.0.0.0:8002

###hostname:port of the default join-GW_MQTT_SERVER
JS_SERVER=http://localhost:8003

###ca certificate used by the default join-server client
JS_CA_CERT=

###tls certificate used by the default join-server client (optional)
JS_TLS_CERT=

###tls key used by the default join-server client (optional)
JS_TLS_KEY=

###installation margin (dB) used by the ADR engine
INSTALLATION_MARGIN=10

###class a rx1 delay
RX1_DELAY=1

###rx1 data-rate offset (valid options documented in the LoRaWAN Regional Parameters specification)
RX1_DR_OFFSET=0

###rx2 data-rate (when set to -1, the default rx2 data-rate will be used)
RX2_DR=-1

4

Is the Gateway Bridge installed on the gateway, if not could you try?

Also, what gateway do you have and which packet-forwarder version is running on it?

5

no, the Bridge is installed on the vmware guest Ubuntu 14.04, and by now it seems impossible to intall the Bridge on our gateway.
Actually, the gateway is manufactured by ourselves, not bought from well-known componies. The packet-forwarder does not running on the Bridge, and we simulated the packet-forwarder on the LoRaWAN node. That’s to say, before the node sending a normal join-request as LoRaWAN Standard provided, the data was processed the way just as what packet-forwarder would do. Once received the packed data, the gateway does nothing but forwarded it to the Gateway Bridge through udp(port 1700). In this way, we are just trying to establish the backend environment, and verify the functionality of Lora Server components such as Gateway Bridge, Lora Server and Lora App Server. The packet-forwarder version we referred is V2.1.0 from github https://github.com/LoraWan/packet_forwarder.
Is this issue relative to packet_forwarder? As I could see, it’s all about the Lora Server components and their configuration, because the join-request message is successfully received and accepted.

6

I think this issue is related to your packet-forwarder simulation. I don’t think this has anything to do with your LoRa Server configuration. It might be that you did not implement the UDP ping meganism / that you implemented only a subset of the packet-forwarder protocol.

7

Besides the UDP ping mechanism, any more mechanisms in packet-forwarder protocol should we realise to just get an join-accept message with our node?

8

The Gateway Bridge is following the protocol as defined by https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT, when your simulator implements that protocol too, you should be good.

9

ok, we’ll follow this protocol.
While I still think this could not explain why the “join-accept” sent by Lora Server is not received by Lora Gateway Bridge in my case? This seems a issue between Lora Server and Lora Gateway Bridge, nothing to do with the simulator as “join-request” is successfully simulated and processed by Lora Server.

10

The issue is that the ping from the packet forwarder triggers the Gateway Bridge to subscribe on the gateway/MAC/tx mqtt topic. So LoRa Server publishes, but the Bridge doesn’t see it.

11

Ok, many thanks, I get it this time and have better understanding on the protocol.
After adding the ping mechanism simulation, I think this issue is solved. I could get logs from Gateway Bridge like below:

time=“2017-12-21T16:58:37+08:00” level=info msg=“backend: subscribing to topic” topic=“gateway/0102030405060708/tx”
time=“2017-12-21T16:59:08+08:00” level=info msg=“backend: packet received” topic=“gateway/0102030405060708/tx”
time=“2017-12-21T16:59:08+08:00” level=info msg=“gateway: sending udp packet to gateway” addr=10.0.10.31:1929 protocol_version=1 type=PullResp

Thank you again, brocaar!

2 Likes
12

@MarkSeth @brocaar

Hi,

Same way when i try to send dowlink message ,i am getting the following error:

> INFO[0282] backend: packet received                      topic=gateway/123456789/tx
> ERRO[0282] could not send TXPacket: gateway does not exist

Note :

backend: subscribing to topic? I am getting this subscribing without any error

Can you please tell me any particular format to send downlink message?

I am using risinghf gateway + lora gateway bridge service

13

123456789 is not a valid Gateway MAC / Gateway ID. It must be a hex encoded string (64 bit). E.g. 0102030405060708.

14

@brocaar

Sorry brocaar ,i have given that for an example .

This is my actual ID : 0102030405060708

15

@brocaar

Now gateway id issue is not coming back.This is the new error:

INFO[4315] backend: publishing packet                    qos=0 topic=gateway/0102030405060708/stats
INFO[4316] backend: packet received                      topic=gateway/0102030405060708/tx
ERRO[4316] backend: decode tx packet error: invalid character 'â' looking for beginning of object key string

This is the sample message which i published from my server : (i am using aws iot)

{“txInfo”:{“mac”:“0102030405060708”,“immediately”:false,“timestamp”:3517348611,“frequency”:927500000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:9,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:null},“phyPayload”:“gAIAAACABgAFQMU6t5cqon8=”}

I am using semtech packet forwarder

16

Validate your JSON object: https://jsonlint.com/

1 Like
17

@brocaar

Thanks brocaar! Its my mistake .
But still i am getting the following error :

INFO[7684] backend: packet received                      topic=gateway/b827ebfffec3bd9e/tx
ERRO[7684] could not send TXPacket: gateway does not exist

Please advise me any particular format for downlink message ?

Note : Uplink works fine

18

@brocaar

Its working now! we have some minor issue in config file.

Downlink is happening fine,but in packet forwarder its throws this error.

src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3033313238, packet=2888505267, type=0)
ERROR: Packet REJECTED (jit error=2)

But my gateway is displaying current date-time perfectly.