I found help in TTN SLACK #packet-forwarder:
This error in particular occurs because the Go toolchain tries to retrieve the TTN API from the ttn GitHub repo, which has been removed in the latest versions. The best, at this point, is to ignore the error, and to just continue with the regular build instructions (https://github.com/TheThingsNetwork/packet_forwarder/blob/master/docs/INSTALL_INSTRUCTIONS/SPI.md). The error will fix itself with make deps.
Hello everyone,
We’re going to put the development of our Packet Forwarder on hold for the moment. Everyone is still free to use it, and to choose the one they’d like to run on their gateway depending on the requirements. We realised developing our own packet forwarder wasn’t the right approach to the problems we wanted to solve in the first place.
We have started working on another solution for gateways. Our focus will be less on the packet forwarding logic, and more on the everyday maintenance of a gateway. Configuring a gateway, managing it, making sure it runs and stays connected is still a massive pain today (hence some discussions on the forum). There have already been great contributions from the community in that regard, such as the resin.io set up: we’re working on something that goes in the same direction of making gateways easier to manage.
So what’s the recommendation for the best packet forwarder going forward? Is the TTN protocol still in development moving forward or just the forwarder itself?
I’m setting up a few gateways at the moment and want to ensure they have the best supported solution.
We’re still developing our own protocol. We’ll update the TTN packet forwarder if there are minor changes to the API, but if we make major breaking changes to our protocol at some point, we might stop updating the TTN packet forwarder.
For this reason, I’d rather recommend installing Semtech-based packet forwarders if you’re aiming for low gateway maintenance. But depending on your requirements, you might still want to install the TTN packet forwarder for other reasons (e.g. if you need reliable connectivity).
As core team representative on this forum, I am appalled by your response. Will the core team please go have a meeting to discuss how best to support your users. There is an innate responsibility for TTN to provide a solution that meets the aims of the LoRa Alliance. TTN have built a great community over the past 2 years and facile comments about “Semtech code for low maintenance, TTN code for reliable connectivity” dismisses the efforts of the community to build stable solutions.
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?
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?
We’re planning to open-source what we’re working on, yes 
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
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?)
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
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.
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.)
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.
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.
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:
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
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.