chirpstack/chirpstack-gateway-bridge

ChirpStack Gateway Bridge abstracts Packet Forwarder protocols into Protobuf or JSON over MQTT.

ChirpStack Gateway Bridge

ChirpStack Gateway Bridge is a service which converts LoRa^® Packet Forwarder protocols into a ChirpStack common data-format (JSON and Protobuf). This component is part of the ChirpStack open-source LoRaWAN^® Network Server project.

Backends

The following packet-forwarder backends are provided:

• Semtech UDP packet-forwarder
• Basic Station packet-forwarder
• ChirpStack Concentratord

Integrations

The following integrations are provided:

• Generic MQTT broker
• GCP Cloud IoT Core MQTT Bridge
• Azure IoT Hub

Documentation

Please refer to the ChirpStack documentation for more information.

License

ChirpStack Gateway Bridge is distributed under the MIT license. See LICENSE.

chirpstack-gateway-bridge's Issues

Error gateway: could not handle packet: parsing time

Bridge version=2.1.0

Bridge Log#####

INFO[0000] backend: connecting to mqtt broker            server=tcp://127.0.0.1:1883
INFO[0000] gateway: starting gateway udp listener        addr=0.0.0.0:1700
INFO[0000] backend: connected to mqtt broker            
INFO[0004] gateway: received udp packet from gateway     addr=192.168.1.155:43002 protocol_version=1 type=PullData
INFO[0004] backend: subscribing to topic                 topic=gateway/1234567887654321/tx
INFO[0004] gateway: sending udp packet to gateway        addr=192.168.1.155:43002 protocol_version=1 type=PullACK
INFO[0004] gateway: received udp packet from gateway     addr=192.168.1.155:43001 protocol_version=1 type=PushData
ERRO[0004] gateway: could not handle packet: parsing time ""2011-01-01T06:04:25Z"" as ""2006-01-02 15:04:05 MST"": cannot parse "T06:04:25Z"" as " "  addr=192.168.1.155:43001 data_base64=AZh8ABI0VniHZUMheyJzdGF0Ijp7InRpbWUiOiIyMDExLTAxLTAxVDA2OjA0OjI1WiIsInJ4bmIiOjE2LCJyeG9rIjoxMiwicnhmdyI6MTIsImFja3IiOjMyLCJkd25iIjowLCJ0eG5iIjowfX0=

Gateway Log #####

Aug 20 01:44:28 mqtt loraserver[22247]: time="2016-08-20T01:44:28+08:00" level=info msg="backend/controller: publishing rxinfo payload" topic="application/aaffee11ee11eeaa/node/4a30b001adcfff99/rxinfo"
Aug 20 01:44:28 mqtt loraserver[22247]: time="2016-08-20T01:44:28+08:00" level=info msg="backend/application: publishing rx payload" topic="application/aaffee11ee11eeaa/node/4a30b001adcfff99/rx"
Aug 20 01:44:28 mqtt loraserver[22247]: time="2016-08-20T01:44:28+08:00" level=info msg="node-session saved" dev_addr=06cf80c4
Aug 20 01:44:35 mqtt loraserver[22247]: time="2016-08-20T01:44:35+08:00" level=info msg="backend/gateway: rx packet received"
Aug 20 01:44:35 mqtt loraserver[22247]: time="2016-08-20T01:44:35+08:00" level=info msg="packet(s) collected" dev_eui=4a30b001ad1aff88 gw_count=1 gw_macs=1234567887654321 mtype=UnconfirmedDataUp
Aug 20 01:44:35 mqtt loraserver[22247]: time="2016-08-20T01:44:35+08:00" level=info msg="backend/controller: publishing rxinfo payload" topic="application/aaffee11ee11eeaa/node/4a30b001ad1aff88/rxinfo"
Aug 20 01:44:35 mqtt loraserver[22247]: time="2016-08-20T01:44:35+08:00" level=info msg="backend/application: publishing rx payload" topic="application/aaffee11ee11eeaa/node/4a30b001ad1aff88/rx"
Aug 20 01:44:35 mqtt loraserver[22247]: time="2016-08-20T01:44:35+08:00" level=info msg="node-session saved" dev_addr=06bd9704
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=info msg="backend/gateway: rx packet received"
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=warning msg="invalid FCnt" dev_addr=078ee25d dev_eui=1122aaeeffddcc23 packet_fcnt=15 server_fcnt=68
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=error msg="processing rx packet error: invalid FCnt or too many dropped frames" data_base64="QF3ijgeADwAJwzclEO2Zz23qvxuYEuKjUo1lFNkXtiF9yo0E6TsM4A=="
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=info msg="backend/gateway: rx packet received"
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=warning msg="invalid FCnt" dev_addr=078ee25d dev_eui=1122aaeeffddcc23 packet_fcnt=15 server_fcnt=68
Aug 20 01:44:54 mqtt loraserver[22247]: time="2016-08-20T01:44:54+08:00" level=error msg="processing rx packet error: invalid FCnt or too many dropped frames" data_base64="QF3ijgeADwAJwzclEO2Zz23qvxuYEuKjUo1lFNkXtiF9yo0E6TsM4A=="

OTAA Node - does not get activated

Hi,

thanks to @brocaar for this great piece of work!

I tried to connect a lopy node with OTAA (https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node.py) to a single channel gateway (https://github.com/tftelkamp/single_chan_pkt_fwd with http://wiki.dragino.com/index.php?title=Lora/GPS_HAT).
So far connection between node - gateway and gateway-bridge works fine, but i think the node does not get the acitvation message it still sends join requests and the gateway bridge always replies with join accept:

That happens multiple time each minute:

Did is miss something? Maybe some one use the same libraray and has success?

Loraserver Loraappserver and Loragatewaybridge AND single_chan_pkt_fwd run on the same rpi.

Thanks in advance,
best regards
Andreas

.... if this is the wrong section and would be better placed in loraserver section - please let me know!

Expose scheduling errors over MQTT

• add random token to tx payload
• expose errors (including given random token) over MQTT for monitoring

This feature makes it possible to monitor which frames could not be transmitted and why.

Multitech conduit issue

Thanks for your work.
I try to use your projet with Multitech Conduit in packetforwarder, but it doesn't work.
I have messages like this :
time="2016-06-13T09:48:43+02:00" level=error msg="gateway: could not handle pack
et: gateway: invalid protocol version" addr=192.168.1.93:58730 data_base64=AflXA
gCAAAAAALbF
I need help !!!
Arnaud

otaa mode cannot connect

pktfwd local_conf.json
"serv_port_up": 1680,
"serv_port_down": 1680
the node join success
+JOIN: Starting
+JOIN: NORMAL, count 1, 0s, 0s
+JOIN: Network joined
+JOIN: NetID 000000 DevAddr 01:65:14:01
+JOIN: Done

when changed
"serv_port_up": 1700,
"serv_port_down": 1700
restart pktfwd and start ./lora-gateway-bridge --mqtt-server tcp://x.x.x.x:1883
the node join failed
+JOIN: Starting
+JOIN: NORMAL, count 1, 0s, 0s
+JOIN: Join failed

Hi I have some problem on implementation

Sorry I have fixed the problem 👍 haha.

No /etc/lsb-release under Debian

Hi,

Here https://docs.loraserver.io/lora-gateway-bridge/getting-started/#setting-up-lora-gateway-bridge you
use the file /etc/lsb-release that does not exist under Debian Jessie, you have to use the lsb_release command instead.

source /etc/lsb-release
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00
sudo echo "deb https://repos.loraserver.io/${DISTRIB_ID,,} ${DISTRIB_CODENAME} testing" | sudo tee /etc/apt/sources.list.d/loraserver.list
sudo apt-get update

You can replace source /etc/lsb-release by

export DISTRIB_ID=`lsb_release -si`;export DISTRIB_CODENAME=`lsb_release -sc`

Provide arm64 builds

when i used mosquitto_sub -v -t "gateway/+/rx" on ubuntu, it returned "Connection refused: not authorised". that's why ? I have entered MQTT username and password! Could u help me?

Is this a bug or a feature request?

What did you expect?

What happened?

What version are your using?

How can your issue be reproduced?

Could you share your log output?

log errors on MQTT authentication

when anonymous auth is disabled and you log in with wrong user/password the services stops / restart loops but does not log why. It should log something like 'MQTT login access denied for user xxxx'

IP Address of the gateway

Hi :)

I think that the IP of the gateway could be an interesting information to add to the topic /gateway/[MAC]/stats.

The information about the IP is already available, and is not complex to add it to the MQTT message, however it will add a lot of flexibility to complex networks.

I would like to have your opinion about this.

I may implement this by myself and provide a PR.

unable to get correct configuration

hi,
i installed debian package of lora-gateway-bridge on raspberry pi 3 and i edited config file in

/etc/default/lora-gateway-bridge
/usr/lib/lora-gateway-bridge/scripts/default

but when run "sudo systemctl start lora-gateway-bridge" i get :

lora-gateway-bridge.service - lora-gateway-bridge
Loaded: loaded (/etc/systemd/system/lora-gateway-bridge.service; disabled)
Active: failed (Result: start-limit) since ven 2017-02-10 07:27:07 CET; 9min ago
Process: 3325 ExecStart=/opt/lora-gateway-bridge/bin/lora-gateway-bridge (code=exited, status=203/EXEC)
Main PID: 3325 (code=exited, status=203/EXEC)

feb 10 07:27:06 raspberry systemd[1]: Unit lora-gateway-bridge.service entered failed state.
feb 10 07:27:07 raspberry systemd[1]: lora-gateway-bridge.service holdoff time over, scheduling restart.
feb 10 07:27:07 raspberry systemd[1]: Stopping lora-gateway-bridge...
feb 10 07:27:07 raspberry systemd[1]: Starting lora-gateway-bridge...
feb 10 07:27:07 raspberry systemd[1]: lora-gateway-bridge.service start request repeated too quickly, refusing to start.
feb 10 07:27:07 raspberry systemd[1]: Failed to start lora-gateway-bridge.
feb 10 07:27:07 raspberry systemd[1]: Unit lora-gateway-bridge.service entered failed state.

if i run "/usr/bin/lora-gateway-bridge" i get:

INFO[0000] starting LoRa Gateway Bridge docs=https://docs.loraserver.io/lora-gateway-bridge/ version=2.1.2
INFO[0000] backend: connecting to mqtt broker server=tcp://127.0.0.1:1883
FATA[0000] could not setup mqtt backend: Network Error : dial tcp 127.0.0.1:1883: getsockopt: connection refused

but the value of mqtt server doesn't match the value set in config file that i've edited.

the correct config and the app run only if i run "/usr/lib/lora-gateway-bridge/script/init.sh start".

i'm available for any information.

thanks!

Bridge stops processing packets

I have noticed a problem when using a Microchip gateway where the gateway bridge appears to get confused and stops talking to the server. I am unsure how to reproduce the problem but on several occasions yesterday I noticed that one of my microchip motes could no longer join the network and when I looked further into the problem, the gateway bridge did not appear to be talking to the server. When I restarted the gateway, the problem persisted. When I restarted the gateway bridge and gateway, the problem went away and the server started receiving data again. At the time, I was changing some gateway configuration parameters while attempting to get some Laird motes to join. I do not recall exactly what I did but at one time I change the sync word from 0x34 to 0x12 and back again. It happened another time and I do not recall it had anything to do with the sync word.

Kerlink Wirnet Dual Antenna Support

Hi,

the Kerlink Wirnet iBTS seems to struct the rx Data a little different (see UDP Dump below), when using two antennas and standard pkt-forwarder. That way the gateway bridge doesn't seem to be able to handle RSSI and SNR correctly, when carrying over to MQTT. Would it be possible to add support for that?

Greetings
Finn

{
	"rxpk": [{
		"tmst": 879148780,
		"time": "2017-07-04T13:51:17.997099Z",
		"rfch": 0,
		"freq": 868.500000,
		"stat": 1,
		"modu": "LORA",
		"datr": "SF7BW125",
		"codr": "4/5",
		"size": 24,
		"data": "gM+AMQcAvgQBlohnlJqUGOJKTDuTscQD",
		"rsig": [{
			"ant": 0,
			"chan": 7,
			"rssic": -95,
			"lsnr": 14.0,
			"etime": "42QMzOlYSSPMMeqVPrY0fQ==",
			"rssis": -95,
			"rssisd": 0,
			"ftime": 1255738435,
			"foff": -8898,
			"ft2d": -251,
			"rfbsb": 100,
			"rs2s1": 97
		}, {
			"ant": 1,
			"chan": 23,
			"rssic": -88,
			"lsnr": 14.0,
			"etime": "djGiSzOC+gCT7vRPv7+Asw==",
			"rssis": -88,
			"rssisd": 0,
			"ftime": -1252538435,
			"foff": -8898,
			"ft2d": -187,
			"rfbsb": 100,
			"rs2s1": 104
		}]
	}]
}

Gateway KeepAlive is not communicated over mqtt

Is this a bug or a feature request?

Bug (I guess) - I don't know if it should be created here or in Lora-app-server

What did you expect?

To receive each keep alive or communication message through gateway bridge

What happened?

For some time packets were not appearing on mqtt but communicating through gateway bridge

What version are your using?

2.1.5

How can your issue be reproduced?

No idea

Could you share your log output?

Lora-gateway-bridge log output - it's working fine but no message when subscribing to mqtt for sometimes (recieving packets at random time not all the time)
time="2017-10-13T09:10:41Z" level=info msg="gateway: sending udp packet to gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullACK time="2017-10-13T09:10:51Z" level=info msg="gateway: received udp packet from gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullData time="2017-10-13T09:10:51Z" level=info msg="gateway: sending udp packet to gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullACK time="2017-10-13T09:11:01Z" level=info msg="gateway: received udp packet from gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullData time="2017-10-13T09:11:01Z" level=info msg="gateway: sending udp packet to gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullACK time="2017-10-13T09:11:11Z" level=info msg="gateway: received udp packet from gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullData time="2017-10-13T09:11:11Z" level=info msg="gateway: sending udp packet to gateway" addr=14.102.105.90:56640 protocol_version=1 type=PullACK

Installing LoRa Gateway Bridge on Raspberry Pi

I made an attempt to install Lora Gateway Bridge on a Raspberry pi model 3 B using the following instructions which were provided for on Loraserver.io.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00

export DISTRIB_ID=`lsb_release -si`
export DISTRIB_CODENAME=`lsb_release -sc`
sudo echo "deb https://repos.loraserver.io/${DISTRIB_ID,,} ${DISTRIB_CODENAME} testing" | sudo tee /etc/apt/sources.list.d/loraserver.list
sudo apt-get update

However, when I do, I receive the following error.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.xmX1WzZ4d2 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00
gpg: requesting key 6DBCCA00 from hkp server keyserver.ubuntu.com
gpg: key 6DBCCA00: "Orne Brocaar <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
pi@raspberrypi:~ $ export DISTRIB_ID=`lsb_release -si`
pi@raspberrypi:~ $ export DISTRIB_CODENAME=`lsb_release -sc`
pi@raspberrypi:~ $ sudo echo "deb https://repos.loraserver.io/${DISTRIB_ID,,} ${DISTRIB_CODENAME} testing" | sudo tee /etc/apt/sources.list.d/loraserver.list
deb https://repos.loraserver.io/raspbian jessie testing
pi@raspberrypi:~ $ sudo apt-get update
Hit http://archive.raspberrypi.org jessie InRelease                                 
Hit http://mirrordirector.raspbian.org jessie InRelease                             
Get:1 https://repos.loraserver.io jessie InRelease [162 B]                          
Ign https://repos.loraserver.io jessie InRelease                              
Get:2 https://repos.loraserver.io jessie Release.gpg [162 B]                  
Ign https://repos.loraserver.io jessie Release.gpg                                                                
Get:3 https://repos.loraserver.io jessie Release [162 B]                                                          
Ign https://repos.loraserver.io jessie Release                              
Get:4 https://repos.loraserver.io jessie/testing armhf Packages [162 B]     
Get:5 https://repos.loraserver.io jessie/testing Translation-en_GB [162 B]                                     
Get:6 https://repos.loraserver.io jessie/testing Translation-en [162 B]                                        
Get:7 https://repos.loraserver.io jessie/testing armhf Packages [162 B]               
Get:8 https://repos.loraserver.io jessie/testing Translation-en_GB [162 B]                                     
Get:9 https://repos.loraserver.io jessie/testing Translation-en [162 B]                                        
Get:10 https://repos.loraserver.io jessie/testing armhf Packages [162 B]                                        
Get:11 https://repos.loraserver.io jessie/testing Translation-en_GB [162 B]                                     
Hit http://mirrordirector.raspbian.org jessie/main armhf Packages                                                   
Get:12 https://repos.loraserver.io jessie/testing Translation-en [162 B]                                            
Hit http://mirrordirector.raspbian.org jessie/contrib armhf Packages
Get:13 https://repos.loraserver.io jessie/testing armhf Packages [162 B]
Hit http://archive.raspberrypi.org jessie/main armhf Packages                                
Hit http://mirrordirector.raspbian.org jessie/non-free armhf Packages                              
Get:14 https://repos.loraserver.io jessie/testing Translation-en_GB [162 B]                        
Hit http://mirrordirector.raspbian.org jessie/rpi armhf Packages                                                                            
Get:15 https://repos.loraserver.io jessie/testing Translation-en [162 B]                                                                    
Hit http://archive.raspberrypi.org jessie/ui armhf Packages                                            
Get:16 https://repos.loraserver.io jessie/testing armhf Packages [162 B]                               
Err https://repos.loraserver.io jessie/testing armhf Packages                                                                 
  HttpError404
Get:17 https://repos.loraserver.io jessie/testing Translation-en_GB [162 B]                                                   
Ign https://repos.loraserver.io jessie/testing Translation-en_GB                                          
Get:18 https://repos.loraserver.io jessie/testing Translation-en [162 B]                                  
Ign https://repos.loraserver.io jessie/testing Translation-en                                          
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en_GB                                                                          
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en                                                                             
Ign http://mirrordirector.raspbian.org jessie/main Translation-en_GB                                                                             
Ign http://mirrordirector.raspbian.org jessie/main Translation-en                                                                                
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en_GB                                                                         
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en                                                                            
Ign http://archive.raspberrypi.org jessie/main Translation-en_GB                                                                                 
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en_GB                                                                              
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en                                                                                 
Ign http://archive.raspberrypi.org jessie/main Translation-en                                                                                    
Ign http://archive.raspberrypi.org jessie/ui Translation-en_GB                                                                                   
Ign http://archive.raspberrypi.org jessie/ui Translation-en                                                                                      
W: Failed to fetch https://repos.loraserver.io/raspbian/dists/jessie/testing/binary-armhf/Packages  HttpError404                                 

E: Some index files failed to download. They have been ignored, or old ones used instead.
pi@raspberrypi:~ $ sudo apt-get install lora-gateway-bridge
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package lora-gateway-bridge
pi@raspberrypi:~ $ 

I would really appreciate your comments and suggestions that would help me solve this issue. Thank you.

Is this a bug or a feature request?

no

What did you expect?

A successfull installation of lora gateway bridge on raspberry pi

What happened?

please see above

What version are your using?

Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

How can your issue be reproduced?

Could you share your log output?

Shared above.

Why UDP??

Just one simple doubt. Why use of UDP for lora-gatewat-bridge.. Can we configure this with TCP/IP???

Port of the server?

What ports enabled on server for specify "serv_port_up" and "serv_port_down" at "gateway_conf"?

question: listening ipv6 instead of ipv4?

When I try to start the Lora gateway bridge, the UDP listener ends up creating an ipv6 service instead of ipv4. I've tried to force it by editing backend.go (approx line 100) to have:

conn, err := net.ListenUDP("udp4", addr)

However, netstat -lun still shows it as listening only via udp6:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
udp        0      0 127.0.0.1:323           0.0.0.0:*                          
udp        0      0 0.0.0.0:32683           0.0.0.0:*                          
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp6       0      0 ::1:323                 :::*                               
udp6       0      0 :::38377                :::*                               
udp6       0      0 :::1700                 :::*   

Is that normal?

Edit: in my /etc/default/lora-gateway-bridge file I have "UDP_BIND=0.0.0.0:1700" specified.

ca certificate format

Is this a bug or a feature request?

Somewhere between a bug, a feature, and some info on the docs I guess ;)

What did you expect?

Well, I don´t know what file format to use for the --mqtt-ca-cert option

What happened?

I used pem and der format for the CA, but I got this error:

ERRO[0000] could not setup mqtt backend, retry in 2 seconds: Network Error : x509: certificate signed by unknown authority

Also, just to try, I passed any other file (not a certificate, i.e. the start.sh file suggested for kelink), and it gives the same error, it doesn't tell me there's an error on the certificate itself.

What version are your using?

lora-gateway-bridge version 2.1.5

How can your issue be reproduced?

Just try to use the --mqtt-ca-cert option not knowing the right certificate format ;)

/user/lora-gateway-bridge/bin/lora-gateway-bridge --mqtt-server ssl://dev-marting-3.exo.local:1883 --mqtt-ca-cert /user/lora-gateway-bridge/certnew.cer

Could you share your log output?

/user/lora-gateway-bridge/bin/lora-gateway-bridge --mqtt-server ssl://dev-marting-3.exo.local:1883 --mqtt-ca-cert /user/lora-gateway-bridge/certnew.cer
INFO[0000] starting LoRa Gateway Bridge                  docs="https://docs.loraserver.io/lora-gateway-bridge/" version=2.1.5
INFO[0000] backend: connecting to mqtt broker            server="ssl://dev-marting-3.exo.local:1883"
ERRO[0000] could not setup mqtt backend, retry in 2 seconds: Network Error : x509: certificate signed by unknown authority
INFO[0002] backend: connecting to mqtt broker            server="ssl://dev-marting-3.exo.local:1883"
ERRO[0002] could not setup mqtt backend, retry in 2 seconds: Network Error : x509: certificate signed by unknown authority

Multiple end-nodes join issue

Hi Orne,

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

where to run packet forwarder

Hi Brocaar,

I have done the setup given by you.
I m having Microchip gateway and motes. I m running the lora-gateway-bridge, loraserver, lora-app-server shared by you.

I m getting the packets from microchip gateway to the lora gateway bridge.
But I m getting the following error.

Error gateway: could not handle packet: parsing time

You said that running the three software only was required for the setup. Do I have to run packet forwarder too ?
If yes, where?

P.S. this question was already asked but it was closed and it did not solve my query.

Dequeue-ing, but not transmitting?

This is in reference to brocaar/chirpstack-application-server#114

Symptoms:

• I am queueing downlink packets with RESTful API, and I see the downlink queue getting populated.
• I also see the downlink queue de-populate when the mote with the correct DevEUI communicates to the server.
• Using a python sniffer, I do not see PULL_RESP packets going to the gateway, only PULL_ACK.

Hardware:

• Mirakonta Gateway setup of RPi + USB-MTAC.
• Bridge/server/app-server running on a remote VM.
• Mote is an mbed mDot.

The original question asked for debugging guidance and what configuration settings I may be overlooking that might cause this.

Thank you... if you need more information, I'll be happy to provide it. I'll try to get you the log file(s) as soon as possible.

mosquitto_sub -t "gateway/+/rx" time message was not set

lora_pkt_fwd : Version 3.0.0
log_lora-gateway-bridge : Version 2.1.0-3-gedf27bf

when I subscribe gateway's rx
time was not set like this.

"time":"0001-01-01T00:00:00Z"

log file is below.

log_lora-gateway-bridge-2.1.0-3-gedf27bf.txt
log_packet_forwarder-3.0.0.txt
log_mqtt_gateway_rx.txt

Send packets to node

I've install the packet_forward and the lora_gateway_bridge on a raspberry pi and the rest (server and all that) on a remote server.
The joining and node sending data to the server works but i dont seem to be able to send packets when publishing on mqtt. I've tried both with the message to the gateway and message to the end device (the 2 examples in the tutorial)

Build binary lora-gateway-bridge with fix configuration inside

Hi,
Is it possible to include the configuration inside the binary file?

https://forum.loraserver.io/t/build-binary-lora-gateway-bridge-with-fix-configuration-inside/105

Thanks

Support for The Things Network backend

The upcoming version of The Things Network's backend will use gRPC streams to communicate with gateways. The protocol is defined in this .proto.

I have started implementing an alternative to the mqttpubsub backend that will use these gRPC streams in order to bridge to The Things Network.

Does the gateway bridge support the packet forwarder v2 v4.0.0

Is this a bug or a feature request?

Feature request

What version are your using?

latest

How can your issue be reproduced?

I am using kerlink IBTS, I installed the packet forwarder v2 v4.0.0 on it but seems like the gateway bridge is not supporting it, since I am getting 0 for RSSI and SNR values.

This issue is related to: https://github.com/brocaar/lora-gateway-bridge/issues/44
since the packet forwarder protocol is not the same.

Thanks,
Best reagrds

Location configuration for the TLS CA certificate

I try to install the lora-gateway-bridge on the gateway including MQTT TLS.
How can I configure the location configuration for the TLS CA certificate?

Backward compatibility of protocol v1

Many gateways deployed in the field will not be updated any time soon to protocol v2. This means that there's possibly a long overlap of v1 and v2 gateways. This would mean a) that we'd need to have two endpoints for both protocols, which is a configuration setting on the gateway, while the protocol is built in the software. So, b) when using configuration files from wiki, forums, etc., often with the intention to get the frequency plan right, one should also take care of the endpoint.

Is it feasible to make version 2.x of this bridge backward compatible with the v1 protocol? The first byte of the messages indicate the version, so it seems to be a matter of deserializing the payload.

Re-subscribe on tx topic after mqtt connection loss

Support for openwrt and mips

If one of the designs is to have the lora-gateway-bridge running on the gateway itself
and use MQTT instead of UDP.
It would be nice if the lora-gateway-bridge would support platforms like OpenWrt (mips, ar71xx),
as some gateway uses it.

(edit: just learn that the go application compiled is pretty large, maybe the lora-gateway-bridge running on a OpenWrt gateway is better written in C?)

Cheers!

Log node frames not appearing

bug

I want to see the packets recieved in the frame_log

in loraserver config file LOG_NODE_FRAMES is set to true

loraserver version 0.20.0

FSK downlink needs fdev set

Please add fdev to the FSK txpk, with a value of 25000.

ipol you can remove (it only applies to LORA).

JSON down: {"txpk":{"imme":false,"tmst":1082005352,"freq":868.8,"rfch":0,"powe":14,"modu":"FSK","datr":50000,"ipol":false,"size":12,"data":"YFR4RQIgAACSQU77"}}
WARNING: [down] no mandatory "txpk.fdev" object in JSON, TX aborted

[SOLVED] gateway: could not handle packet: json: cannot unmarshal number into Go value of type uint32

Hi,
I'm trying to configure a Lora server in my PC, and already installed mosquitto and the lora-gateway-bridge. As shown in the log, It's receiving the Keepalive and stat packets sent from the gateway OK but when data is sent from the modules, I always get this error:

level=error msg="gateway: could not handle packet: json: cannot unmarshal number 473387129083000 into Go value of type uint32"

the value 473387129083000, is the 'tmst' parameter, as shown in the output of the python script for
reading data received from the packet-forwarder gateway.

tmst = number | Internal timestamp of "RX finished" event (32b unsigned)

Python script output:

Data received from Gateway: xx:xx:xx:6D:7D

{u'rxpk': [{u'stat': 1, u'modu': u'LORA', u'lsnr': 7.0, u'chan': 0, u'datr': u'SF7BW125', u'tmst': 473386384150000L, u'codr': u'4/5', u'rfch': 1, u'time': u'2015-01-01T00:13:04.000000Z', u'rssi': -40, u'freq': 868.3, u'data': u'gLgCAGAADgACQ0FGRd6mSaA=', u'size': 17}]}

{u'stat': 1, u'modu': u'LORA', u'lsnr': 7.0, u'chan': 0, u'datr': u'SF7BW125', u'tmst': 473386384150000L, u'codr': u'4/5', u'rfch': 1, u'time': u'2015-01-01T00:13:04.000000Z', u'rssi': -40, u'freq': 868.3, u'data': u'gLgCAGAADgACQ0FGRd6mSaA=', u'size': 17}

Lora-gateway-bridge Log:

time="2017-05-09T13:33:04+02:00" level=info msg="gateway: stat packet received" addr=10.10.1.238:15555 mac=xxxxxx6d647d0000
time="2017-05-09T13:33:04+02:00" level=info msg="backend: publishing packet" topic="gateway/xxxxxx6d647d0000/stats"
time="2017-05-09T13:33:04+02:00" level=info msg="gateway: sending udp packet to gateway" addr=10.10.1.238:15555 protocol_version=1 type=PushACK
time="2017-05-09T13:33:08+02:00" level=info msg="gateway: received udp packet from gateway" addr=10.10.1.238:15555 protocol_version=1 type=PullData
time="2017-05-09T13:33:08+02:00" level=info msg="gateway: sending udp packet to gateway" addr=10.10.1.238:15555 protocol_version=1 type=PullACK
time="2017-05-09T13:33:23+02:00" level=info msg="gateway: received udp packet from gateway"
time="2017-05-09T13:33:33+02:00" level=info msg="gateway: received udp packet from gateway" addr=192.168.10.26:15555 protocol_version=1 type=PushData

time="2017-05-09T13:33:33+02:00" level=error msg="gateway: could not handle packet: json: cannot unmarshal number 473387129083000 into Go value of type uint32" addr=192.168.10.26:15555 data_base64=ARRVANiAOW1kfQAAeyJyeHBrIjpbeyJ0bXN0Ijo0NzMzODcxMjkwODMwMDAsInRpbWUiOiIyMDE1LTAxLTAxVDAwOjI1OjI5LjAwMDAwMFoiLCJjaGFuIjowLCJyZmNoIjoxLCJmcmVxIjo4NjguMzAwMDAwLCJzdGF0IjoxLCJtb2R1IjoiTE9SQSIsImRhdHIiOiJTRjdCVzEyNSIsImNvZHIiOiI0LzUiLCJsc25yIjo3LjAsInJzc2kiOi0zNSwic2l6ZSI6MTcsImRhdGEiOiJnTGdDQUdBQUZRQUNRMEZHUmVMeVpQaz0ifV19

I don't know why this 'tmst' value is so big and does not allocate in the size of the uint32 variable. It's automatically generated, so, it should comply....

I'm using Nemeus MK002 module and MG003-EU-1.1 gateway configured as packet forwarder.

Any help would be appreciated,
Thanks in advance.

Lorank8 status message support

See:
TheThingsArchive/ttn#427

In short, the Lorank8 by default uses a different JSON format for its status messages. Example:
{"time":"2017-01-19T18:02:38Z","dev":{"id":"1dee039aac75c307","lat":52.2388,"lon":6.8551,"alt":6,"up":93,"gps":"fake","pfrm":"Lorank","email":"[email protected]","desc":"TTN Enschede macrocell gateway"},"prf":{"up_rf":0,"up_srv_dg":[0,1],"dw_srv_hb":[0.8333333333,1],"dw_srv_dg":[0,0],"dw_rf":[0.8333333333,1],"dw_bcn":0}}

It will be great if this bridge can support the Lorank8 protocol too.

I can use it ,but i can't make it ,why?

Hi,
i want to compile the project ,but some errors happen .
$ make

Compiling source for linux
cmd/lora-gateway-bridge/main.go:10:2: import "github.com/Sirupsen/logrus": cannot find package
cmd/lora-gateway-bridge/main.go:11:2: import "github.com/brocaar/lora-gateway-bridge/backend/mqttpubsub": cannot find package
cmd/lora-gateway-bridge/main.go:12:2: import "github.com/brocaar/lora-gateway-bridge/gateway": cannot find package
cmd/lora-gateway-bridge/main.go:13:2: import "github.com/brocaar/lorawan": cannot find package
cmd/lora-gateway-bridge/main.go:14:2: import "github.com/codegangsta/cli": cannot find package
make: *** [build] Error 1

newTXPKFromTXPacket miss RFCh

TXPK defind RFCh but newTXPKFromTXPacket method don't use RFCh

Question: Can we really infer uplink vs downlink based on PushData vs PullData

Hi,

Really nice job with the packet parser and this bridge (and also the server 😄)!

I have a question related to this one (related to uplink field in PHYPayload). In the current implementation it seems to me that whenever a packet is received on the UDP port and it is PushData, it is assumed to be uplink (this part of the implementation approximately). I believe it is possible, for example, to receive an Unconfirmed Data Down send from another antenna (if two antennas are close enough). In this case the antenna that receives the packet will provide it to the bridge as PushData. In that case I think that the current implementation will not work correctly. Am I misunderstanding the implementation?

If I am correct, I believe that the option with MType is the way to go. The reason for this is that as you said, it should work for every message type except Proprietary and I don't think that there is any guarantee that there will be FHDR in a Proprietary message (or that you can assume anything more than the fact that it will have MHDR and MIC). I might be wrong of course.

Consequently, I would expect Proprietary messages to have only a payload field that is the bytes of the MACPayload or something similar and a custom server to know how to handle this.

Do you have other reasons to prefer the current implementation and does this seems reasonable to you?

sudo-apt get update error.

Is this a bug or a feature request?

What did you expect?

What happened?

What version are your using?

How can your issue be reproduced?

Could you share your log output?

Microchip LoRa Gateway: Parsing time error (issues with stat packet)

Hi Broccar,
we are in the testing phase of Lora server with Microchip Lora Gatwey version 1.0.4.
We had this error:

feb 16 23:02:29 ******** lora-gateway-bridge[12324]: time="2017-02-16T23:02:29+01:00" level=error msg="gateway: could not handle packet: parsing time ""2017-02-16T22:01:57Z"" as ""2006-01-02 15:04:05 MST"": cannot parse "T22:01:57Z"" as " "" addr=****:43001 data_base64=AXEKABI0VniHZUMheyJzdGF0Ijp7InRpbWUiOiIyMDE3LTAyLTE2VDIyOjAxOjU3WiIsInJ4bmIiOjc4LCJyeG9rIjozMiwicnhmdyI6MzIsImFja3IiOjEsImR3bmIiOjIwLCJ0eG5iIjoyMH19

Could you please help us to solve this problem?
Thank you in advance.
Regards

Gilberto

Kerlink iFemtoCell does not send (or lora-gateway-bridge does not receive) timestamp

Kerlink iFemtoCell with Semtech Packet Forwarder does not send (or lora-gateway-bridge does not receive) timestamp.

Packet from Kerlink iFemtoCell:

{"applicationID":"1","applicationName":"0000000000000077","nodeName":"0018b20000000298","devEUI":"0018b20000000298",
"rxInfo":[{"mac":"7276ff00390301cb","rssi":-48,"loRaSNR":6.5,"name":"Kerlink-Home-2","latitude":55.776826451225254,"longitude":37.730076313018806,"altitude":0}],
"txInfo":{"frequency":868500000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":347,"fPort":1,"data":"nx1VRmBgA3Q3kFxbDOA6Bw=="}

Packet from Kerlink LoRa station (Wirnet Station):

{"applicationID":"1","applicationName":"0000000000000077","nodeName":"0018b20000000298","devEUI":"0018b20000000298","rxInfo":[{"mac":"0000024b080e0e0c","time":"2017-06-06T13:45:08.343905Z","rssi":-15,"loRaSNR":9.5,"name":"KERLINK-GTL-EU","latitude":55.77681,"longitude":37.73001,"altitude":89}],"txInfo":{"frequency":868300000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":388,"fPort":1,"data":"nh1VRlmQA3Q3kIV9DOA="}

Install lora-gateway-bridge on a Gateway

I have the Ideetron's LoRa Gateway Lorank8v1.
Could i install on this gateway the lora-gateway-bridge service in order to send packets via MQTT?
The Gateway by default sends UDP packets.
Thanks a lot!

lora-gateway-bridge can't receive the packet from mote.

I run packet_forwarder and lora-gateway-bridge at the same time and let the LoRa mote send packet to the gateway.
(I used the iC880A as the gateway and the iM880B Starter kit as the mote.)
However, packet_fowrder confirmed that the packet was received, but the lora-gateway-bridge did not respond.

I thought of a problem. But I do not know if this caused this error. If it seems correct, please let me know about the values' ​​setting related server in global_conf.json file of packet forwarder.

I was setting the global_conf.json file of pacekt_forwarder / lora_pkt_fwd. (Server_address: mqtt broker's tcp address, serv_port_up, serv_port_down: mqtt broker's port). But I think it is not right.

I wonder if there might be other problems.

Thank you.

us or eu

does this go code work only for eu ?
if so then what is the US struct ?

type Backend struct {
  | conn mqtt.Client
  | txPacketChan chan gw.TXPacketBytes
  | gateways map[lorawan.EUI64]struct{}
  | mutex sync.RWMutex
  | }
 

test tools

Hi,

Are there any tools that you have or know of to simulate/test the lora-bridge-gateway without having a real gateway with motes up and running?

Cheers
-Anders

Add option for logfile

With the LorixOne Gateway, I have problem to start the gateway as a deamon and to pipe the stout and sterr to a file. START-STOP-DEAMON has a problem with that. I think I have no other options...
The Gateway run with a yocto linux 2.1.2.

Support for custom fields in The Things Network packet forwarder

The Things Network's version of the packet forwarder adds a number of custom fields to the stat message:

• platform
• contact_email
• description

I can implement these fields myself as soon as I have time. If anyone else wants to do this, please add a comment.

mqtt qos support

Hi,
Wouldn't be nice to have mqtt qos = 1 and/or 2 support?
Looking at the code, it seem to be hardcoded to 0.

Cheers
-Anders

Time is always "0001-01-01T00:00:00Z" in MQTT messages (using a LORANK8)

Since a couple of weeks, I noticed that the "time" parameter at the rx packet (in both "gateway" and "application" MQTT packets) is always "time":"0001-01-01T00:00:00Z". I must say that this can be seen since I upgraded my Lorank8, so probably the problem could be with the Lorank software as well. To double-check I started a UDP listener to see if the UDP packets contain time as "zero" as well. Well, the UDP packets that are sent to the lora-gateway-bridge apparently contain the correct time (i.e. "time":"2016-11-03T11:11:25Z","rxpk" ... ). Is this a bug?

A sample UDP dump is attached here:
UDP_20161103-1212.txt

I also include the MQTT payload that is generated by the lora-gateway-bridge from the UDP message with timestamp 8821235:
MQTT_8821235.txt