New TTN Packet Forwarder available

I think the most important question is: will the new developments still be open sourced, or will the community be left to fend with the Semtech forwarders while features such as secure forwarding and ease of gateway maintenance will be reserved for some premium scheme users?

3 Likes

I’m not happy with this response either. I’ve deployed a number of gateways recently using the new code and invested time and effort getting them setup and coverage mapped. Moving back to the Semtech forwarder seems a retrograde step but I need to ensure I have a supported solution.

There are already too many forwarder choices and the TTN solution was a good one for a stable and easy to configure setup. Is there some way support could be continued even through a community effort?

3 Likes

We’re planning to open-source what we’re working on, yes :slight_smile: But we’re still early in the design and development stages. Our current idea revolves around an agent or a daemon that would run on-top of the Semtech packet forwarders, that could manage the PF, act as a bridge to the TTN protocol, and that could be used to control other parts of the gateway (OS, metrics, maybe even remote management?) - this again, in the objective of making gateways easier to manage.

Another change that motivated this decision was the gateway market, that’s getting more prolific - we’re seeing more and more cheap gateways and while that will help expand the global network (for community members that aren’t interested in building a RPi gateway or by the Things Gateway), it requires more documentation and integration work. It was manageable to have a single, go-to PF setup when there were a few go-to gateways like the Kerlink or the Conduit.
There’s now an ever-expanding list of commercial gateways with different systems and interfaces - some of them are even integrating different concentrator setups, with custom packet forwarders like the iBTS. We didn’t find it sustainable to try and integrate with every single one of the gateways - especially since manufacturers are now integrating the Semtech packet forwarder with most new gateways.

When I first read this, I was pretty outraged by the “We’re putting development of TTN packet forwarder on hold” thing. But not so much because of the actual stop of the development, but because you rushed into naming the Semtech one “legacy” everywhere, and now we’re left with legacy only.

I partially understand the need to concentrate efforts and work on what brings more value, but I disagree with the rationale you are putting forward. The gateway market might be expanding, but almost every gateway in the market uses the exact same SX1301 so they all work with the same code. And the beauty of open source is that you don’t have to be responsible for ALL the gateways out there, if you make it work properly for RPi and a generic SX1301, then others can pick up and fork/send you pull requests to extend it to other hardware.

From a technical perspective, having a layer on indirection between a piece of “legacy” code and TTN might work, but is not entirely efficient. I assume you would have the PF service sending UDP packets to localhost just to have another service re-packaging that into TTN’s protocol. Which sounds to me pretty wasteful and fragile (you suddenly have multiple, out-of-process points of failure in one logical piece of code).

The questions posed by @Epyon are also very appropriate and need a very strong response from your side.

Cheers

7 Likes

I actually think that the expanding number of gateways makes this new path much harder than the challenge of making a forwarder work.

Remote admin of different platforms is a much bigger challenge.

I’m almost thinking something along the lines of OpenWRT is needed with a very cutdown secure OS that runs the forwarder and management GUI with little else.

That would require custom Linux images for all those different gateway types with different hardware. I find building the MP forwarder for 4 different (may-be 5 in the future) to be a challenge and for the forwarder the base Linux system is in place. Creating an image for wildly different hardware platforms is not something I would want to tackle. (And what happens to the warranty of off-the-shelf products once you replace the OS image?)

4 Likes

I’m playing devils advocate a little here but I see it that most of the admin you might want to do is operating system related rather than the forwarder itself (assuming it’s running fine). The Pi isn’t ideal for this as it’s generally running behind NAT hence solutions like resin.io and others can make access easier but aren’t perfect.

Reducing the OS footprint limits the security risk and could make updating easier through an automated image based update like a wireless router etc or through the TTN console, thus ensuring all services were fully patched.

It’s a similar model to a wireless router, only that you may be managing them remotely.

I’d rather see the homebrew community running on limited hardware with better support and allowing others to branch support as needed ala OpenWRT

In terms of commercial gateways then the packet forwarder model or some middleware is the better option so not to interfere with any of the built in management

2 Likes

Thanks everyone. It may sound weird but I really appreciate pushback because that means that people actually care.

Gateways are still the biggest pain in the network and I think many Alliance members share that.

Before addressing your concerns, let’s take a few steps back.

Like everyone, we started with the Semtech UDP packet forwarder. Mostly because our focus was on other things. Now, UDP is not secure and not reliable. The forwarder is hard to configure, let alone remotely configurable easily, kept on introducing breaking changes (new formats, drop USB support) and as it’s written in C and the way it is written, it is hard to maintain. Also, the community developed forks to support multiple networks (a bad idea), new protocols (a good idea), we hosted one of those forks, but it diverged with Semtech’s reference design.

Because of all this, we saw a need for a new packet forwarder: use the HAL, a secure and authenticated TCP protocol, written in Go. Sounds simple but it’s not. Now, with a) the availability of so many commercial gateways and SPI settings and constrained hardware and b) the overhead and inevitable complexity, we decided to discontinue the forwarder.

But that is not the whole story. We are working on a major update of The Things Network, which will be announced soon. Part of this, is the Gateway Agent which runs on the Linux gateway and interfaces with the network server, and controls a Semtech based packet forwarder. It generates the global_conf.json file from data from the server: regional parameters, channel plan, the network server to connect to and gateway installation specific settings (max tx power). So it’s the Semtech packet forwarder + the Gateway Agent.

I don’t agree that we rushed with that, but maybe we can improve our communication here. Also, that specific fork is legacy.

We outsource the SX1301 interfacing to the Semtech’s reference design packet forwarder or the manufacturer’s variant of it, so that we can focus on a generic Gateway Agent. I believe that it becomes much easier instead.

Good question. There is no such thing as premium scheme users on The Things Network, and if that will ever exist, security will be there for everyone. The Gateway Agent will be open source. In fact, we are more committed to open source and there will be more open source than there is today, but more about that soon.

2 Likes

What about simply using @kersing’s forwarder then?

(TTN is asking for community help; seems he did a nice job, though I don’t have a gateway to use it on, so have not followed its developments nor have tested it. Even more, given the number of posts/feedback/support about it, at first I didn’t even know it was a different thing than the TTN forwarder, but I thought kersing was working on the “official” thing.)

7 Likes

I very much like the MP forwarder. I think that @kersing can confirm the issues I raised about maintainability and challenging build pipelines, especially when supporting 20+ gateways and versions. This forwarder is therefore more specific to MultiTech gateways. Also it uses our MQTT endpoint which is there to stay and is much better than UDP.

1 Like

Thanks for the reply. Does this mean the new agent will rely on the Semtech UDP protocol or will it convert to something more secure?

Is there a path that works for those of us with gateways now using the TTN forwarder to migrate while maintaining the same gateway IDs? This is important for apps such as ttnmapper.

2 Likes

Yes the Agent let’s the Forwarder talk to itself, to localhost, and then has a secure and authenticated connection with the network server

So, it is fully usable in its current state?

If not, then I guess the following places need to mention the development stop:

1 Like

It’s still fully usable at the moment. You’re right - given that we will probably drop support by the next major version, we’ll add a notice :slight_smile:

I’ve made some test with TTN official, works on RPI3 (not B+ since CPU architecture is different, and compiling with go need some extra work)

You need to know that on PI3, this TTN packet forwarder is eating 10% of CPU and the multi packet from @kersing takes 2% on PI B+. Also compile fine on destination target.

6 Likes

The last reply on this topic was 10 months ago. Did anything change recently? I am new to the TTN community and setting up a Raspberry Pi gateway and I don’t know if I am doing the right thing installing the TTN package forwarder.

I am using the blob as explained in https://github.com/TheThingsNetwork/packet_forwarder/blob/master/docs/INSTALL_INSTRUCTIONS/IMST_RPI.md

1 Like

Hi, I’m also quite new to ttn and would like to know about the current state of development for the gateway<->router interface. I’m not happy with the UDP interface, although it works.

I try to get the gRPC api working from Python, but this is still work in progress. What are the current plans for the future? Is gRPC the way to go?

On https://github.com/TheThingsNetwork/python-app-sdk I can see still some minor contributions which gives me hope.

Cheers

2 Likes

Yeah what is status on this?

I’d like to hear an update also, I got gateways on sat connections not dealing with udp so good.

1 Like

Any brief update would be great. I’m new to the game and I have my gateway up and running, but I also have no idea if I should be using the ttn forwarder or the semtech that is referenced in this article:

https://www.thethingsnetwork.org/docs/gateways/packet-forwarder/ttn.html

Please quick “this one or that one” so I can get going down the right path.

2 Likes