New TTN Packet Forwarder available

Gateways
1

:warning: Update September 2017: development is on hold; see below.

After a couple of weeks of silent beta testing, we’re happy to present to you our new TTN packet forwarder. It’s now publicly available on Github. The current version is v2.0.1, and v2.0.2 is expected to be released in the coming days.

Please visit our Github page to download the packet forwarder. We have detailed manuals for Raspberry Pis, Kerlink IoT Stations and Multitech Conduits. Also, there is documentation available on how to use the packet forwarder for other gateways.

For those who aren’t familiar with the concept, the packet forwarder is a piece of software that is installed on LoRa gateways. It interfaces with the LoRa concentrator to pull and push packets, while interacting at the same time with the network server.

There are a couple of reasons for building a new packet forwarder:

  • On the technical side: Most of the packet forwarders are derived from the original Semtech packet forwarder, which is written in C. The C language has a lot of benefits (we won’t try to start a language war here), but it’s hard to deal with C when you’re used to program in higher-level languages.
    Our network server codebase is entirely written in Go. Go is a compiled language, which generates binaries for stripped-down Linux distributions (very easily, actually), like most gateways. Using Go means that everyone who contributed to the network can now contribute to the packet forwarder. Using a lighter language also gives us more agility to develop new features, and to adapt this packet forwarder to new gateways and chips that will come along - the design takes into account incoming evolutions to LoRa concentrators.

  • On the configuration side: Even after ordering and receiving a gateway, the configuration process of a gateway can be challenging. It can also be hard to troubleshoot issues when they arise. We want to make the packet forwarder setup and maintenance easier. The new packet forwarder includes, for Kerlink IoT Station, Multitech Conduit and Raspberry Pis, builds and packaging scripts. We’ll soon be rolling out other features in the console that will make it even more easier to set up a gateway.

  • On the features side: This new packet forwarder connects using our new gateway protocol. The old Semtech protocol was unsafe (UDP protocol, so didn’t guarantee packet delivery) and not encrypted. The new protocol uses a TCP connection, with native TLS encryption. This means another layer of protection and better troubleshooting. The packet forwarder also implements a JIT queue for the downlinks, leading to a better downlink delivery rate.

There is some confusion arising from old documentation that’s about the old packet forwarder, but that is now linking to the new packet forwarder (since we’re using the same repo as before). If you see any situation like this, feel free to fix it or to point it out!

Just like for the network server, given that it is publicly available on GitHub, this means that you can fork it, and make contributions to it. It can be because you’d like to add a new feature, or because you’ve noticed a bug, or because you’d like to build it for a new kind of gateway…

I want to contribute, but…

  • I don’t know Go: Go is a language that’s easy to learn. It’s compiled, strongly typed, gives a lot of importance to error handling and to code clarity. If you’ve done some C/C++ programming, you’ll feel right at home. If you’re coming from more higher-level languages, the transition will be smooth. You can start developing just after a few hours of tutorials. The Golang official website has resources that will get you started in no time.

  • I don’t know where to start: The list of issues and of features planned for the packet forwarder is publicly available on Github. We recommend keeping an eye on the easy label, that has usually accessible issues, and can give some good insight on how the code is conceived!
    At the moment I’m writing this, these issues can be interesting for whoever wants to contribute:

For those willing to discuss the packet forwarder, feel free to do so here, or to join the #gateways channel on Slack!

(If you’re not using Slack yet, get an invite through https://account.thethingsnetwork.org)

7 Likes
3

As the initial writer of this piece of software, the packet forwarder was written as a demonstration of the SX1301 capabilities. The UDP/cleartext protocol was a conscious choice to keep that part of the program as simple as possible (with no impact on overall security) and maybe discourage its use in a production environment… Apparently, the tolerance for simple & stupid protocols is greater than expected :smiley:

It’s a good thing that replacements are coming, with properly written protocols. Good job!

11 Likes
4

For those, like me, who’re a bit confused now: this is not the same as the new multi-protocol packet forwarder that @kersing has released only recently, and which also supports the TTN protocol, and can connect to other backends.

See also:

5

I wanted to test the new Packet Forwarder on an RPI.
But can not find the imst-rpi-pktfwd.zip anywhere.
Does somebody has any idea?

Compiling from Source failed with:

make deps
packet_forwarder fetching go dependencies
bash: govendor: Kommando nicht gefunden.
.make/go/main.make:85: recipe for target ‘go.deps’ failed
make: *** [go.deps] Error 127

6

@micropet maybe instead of the ZIP you should use the tar.gz in the github repo releases


I haven’t got the right hardware, so cant try this myself - waiting on my TTN gateways…

7

Thank you. I found it.

8

Cool!

Just building on an Odroid XU4.

I seem to have a working go install
I have the paths ok, I think

But when I type in
$ make build

I get this error

In file included from inc/loragw_reg.h:29:0,
from src/loragw_hal.c:26:
inc/config.h:12:22: fatal error: default.h: No such file or directory
compilation terminated.

9

Hi Micropet - I got a similar error when I didn’t have the paths setup correctly.

odroid@odroid:~/go/src/github.com/TheThingsNetwork/packet_forwarder$ make deps
packet_forwarder fetching go dependencies
bash: govendor: command not found
.make/go/main.make:85: recipe for target ‘go.deps’ failed
make: *** [go.deps] Error 127

on Ubuntu LTS 16.04.02 the solution is to check and set the paths

echo “${PATH//:/$’\n’}”
go env GOPATH
export PATH=$PATH:$(go env GOPATH)/bin
export GOPATH=$(go env GOPATH)
echo “${PATH//:/$’\n’}”
go env GOPATH

maybe then check that govendor works
$ govendor

Then when you re-run
$ make deps
you will get some better results

Cheers x

10

Thanks, will try it later.

Peter

11

I have just installed the multi-protocol packet forwarder by Jac Kersing.
Works immediately.

So I have the advantage that I can use several servers.

I still run my own LoRa server installed, this one:

Try a few days, maybe I’ll stick with it.

My Hardware is IMST iC880A LoRaWAN “concentrator” board with an RPI3.

1 Like
12

Does not work for me:

make deps
packet_forwarder fetching go dependencies
Error: Package “/opt/packet_forwarder” not a go package or not in GOPATH.
govendor sync
Ensures the contents of the vendor folder matches the vendor file.
Options:
-n dry run, print out action only
-insecure allow downloading over insecure connection
-v verbose output
.make/go/main.make:85: recipe for target ‘go.deps’ failed
make: *** [go.deps] Error 2

I give up.

14

I very much like the notion of a more reliable means to communicate to/ with TTN. Also like the fact that when running a gateway on one of the more familiar platforms you are good to ‘go’ :wink: so to speak.

I am currently experimenting on creating a multi-channel gateway based on the ic880a / rpi3 using Android Things 0.4-devpreview.There, on such a platform, I do not have golang installed but would very much like to interface using the new packet forwarder in a more direct fashion.

i already downloaded most of the proto files that I think I need (and generated java code from it) but I currently lack some documentation about how a third party like me might be able to successfully connect to the TTN endpoints for successful delivery of the messages and metadata the gateway receives.

I know it’s all new and still in development, nice work!

15

I have the same setup. Do you have a GPS connected to your gateway?
I am trying to connect one to mine with no success.

16

No, I have not connected GPS.
I use the Fake GPS.

What are the advantages of the GPS?

Peter

17

The developers are doing really great work. And everything in her spare time.
I would like to thank you for that.
But…

The documentation is rather poor.
Mostly you have to guess how the source code is compiled.
And this is the most important, if you want to have a current version from the Git master.

It would already be sufficient for the usual platforms (Debian, Ubuntu, Raspberry…) to provide a bash script.

(Which is testet and then works without error !!)

Peter

18

Probably an accurate time on the RPi as well as automatic geo location setup, especially altitude (so you don’t have to guess it). Especially useful for portable gateways which use the mobile phone networks to connect to the internet.

19

Yes OK.

My gateway is in the basement and the antenna is on the roof.
The height I have determined on Google Maps. :slight_smile:
That’s enough for me.

20

Just in case someone else gets this ‘default.h’ No such file or directory error…
Thanks to Eric on the Slack channel - he has said this:
The default.h should be generated automatically depending on the values you, we’re going to fix this. In the meanwhile, you can write your own default.h, based on the imst_rpi.h and kerlink.h in the folder.

21

So just for some clarification, @arjanvanb already mentioned that this is not the same as @kersing 's new packet forwarder. Is there any intention on using kersing’s packet forwarder as the official TTN forwarder in the future? There are already working resin docker deployments for it.

I’m just a little confused on what the status of these side projects are in relation to the official TTN code base. For some reason I had thought kersing’s forwarder was going to be merged into the main code base or something like that.

2 Likes
22

We have a gateway workshop coming up on saturday (10th of june) and decided to stick with the @kersing forwarder, for following reasons:

a) it proved to work on rpi setups very well (i haven’t found any success stories about people installing the official ttn forwarder on a rpi and i searched for a description how to set the reset pin and found nothing in the manual - thats going to be a problem imho for sure)
b) it is state of the art (tcp, ttn protocol, multiple backends) like the official one
c) it has a working docker container and a very easy resin.io install = its future proof, you can switch to the “official” ttn forwarder later if you want and the ttn forwarder has proven to be runing well and someone developed a docker container for it

For these reasons we stick with the @kersing forwarder and watch the ttn one, but we are not using it atm.

2 Likes