thethingsarchive/croft

[OLD] LoRa Croft Gateway Server

Croft

Exposes an UDP endpoint that processes packets from a LoRaWAN gateway and enqueues the message on a RabbitMQ queue, typically consumed by Jolie.

croft's Issues

Post message to MQTT broker

Next to posting the message to RabbitMQ, croft should also post the message to the MQTT broker. Configure with environment variables.

The topic should simply be the device address for now.

No lenght validation on parse message

Croft crashes if the message length is shorter than 12 bytes.

Repro

$ nc -u croft.local 1700
invalid

rssi missing in packages sent by croft

please add the signal strength indicator data to the packages sent to jolie this helps to better understand gateway coverage measurements.

proposal: as the croft lora.RXPK seems to have an Rssi attribute it should be possible to include this in in croft server method convertRXPK.

background/motivation: yesterday @gonzalocasas and me were testing things nodes in zurich with two things nodes. one with a proper antenna and one BETA v1 node.

while packages of the first node were received and displayed on the django rest api http://thethingsnetwork.org/api/v0/nodes// we did not have any luck with thethings uno and its onboard antenna. on mqtt (croft.thethings.girovito.nl:1883) singal strength information also seems missing

having the singal strenght information available in the rest api and on mqtt would help to get a better understanding regading combinations of setups and related ranges.

PUSH_ACK where PULL_ACK expected

I might be wrong here but to me it seems the TTN gateway server is responding wrong to my PULL_DATA requests sent by my Kerlink, causing:

INFO: [down] the last 3 PULL_DATA were not ACKed, exiting application

In the screenshots you can see the PULL_DATA being sent and answered with a PUSH_ACK (0x01) where 0x04 is expected.

Pushed data missing in API

Looking at the data from node 02012902 pushed by gateway 008000000000A050 there are packets missing in the API. The gateway pushes to both TTN and Semtech and as packets are showing at Semtech it looks like there is an issue in the TTN code.

croft parses time incorrect

It looks like croft incorrectly tries to parse timestamps in "stat" and/or "rxpk" packets as rfc822 ("02 Jan 06 15:04 MST") instead of using RFC3339 or something ike that ("2016-01-04 21:04:04 GMT").

Current time seems to be used in this case, which is (almost) correct anyway.

This is shown in the logfile of croft (version installed from GitHub on Jan 3).

Crash by index out of range

At lora/lora.go line 27