Which promised features of Basics Station are currently enabled when using with the Things Stack?

Hi all,

I have a Multitech MPower connected to a locally running instance of the Things Stack (v.3.14.1), with some devices connected to it and data flowing through. However, aside from the authentication of the gateway, I do not see much of a difference between using Basics Station and the regular packet forwarder at this time. It is possible that I’ve just failed to notice a particular menu or something in the web interface, I would appreciate if anyone with experience could assist in helping me use some of the promised features of Basics Station. The features we’re most interested in are:

Centralized Update and Configuration Management: A LoRa Basics Station (“Station”) regularly contacts a separate Configuration and Update Server (CUPS) to check for configuration and software updates, which can include updates to the underlying operating system.

Centralized Channel-Plan Management: Channel plans and other network parameters are managed centrally by the LNS and are read by each Station when a connection is established.

For these two we had assumed that any configuration of the gateway information (channel plan etc) made on the web interface would then be applied directly on the gateway, without the need for us to manually configure the gateway ourselves. But from what I have seen this is not the case, e.g. if I change the frequency plan from EU868 to US915, this does not get applied to the gateway. How can we use TTS with Basics Station to e.g. update our gateway or modify the gateway configuration?

Remote Shell Through LNS Link: The secured IP link to the LNS can be used to run a shell session on a Station. This obviates the need for a reverse SSH tunnel setup. It can be seen as another means to access a gateway in case of problems.

How do I see what this secured IP link is? I don’t see any mention of it in the web interface. I have seen others trying to achieve the same thing on this forum, but there were no clear answers provided: How do you use LoRa Basics Station (CUPS/LNS) for remote management? That was last March though, things make have changed.

Any help with setting up these features would be much appreciated. And if these features are not yet available, if anyone is aware of a public roadmap for development, I would also be very interested in seeing that.

Best regards,

1 Like

Every gateway vendor implements Basic Station differently, so as always, the answer is “it depends”. I only have experience with The Things Indoor Gateway (TTIG), so I can only comment on how it works for those.

We recently used the CUPS feature to rollout the v2.0.4 version of the firmware to a couple thousand TTIGs, which went quite smoothly.

We also use CUPS to (re)configure TTIGs from V2 networks to The Things Stack Community Edition or The Things Stack Cloud. After some hiccups in the beginning, this now also works quite smoothly.

The Things Stack’s LNS implementation sends channel configuration to Basic Station gateways when they connect. Changing from EU868 to US915 may not work, because most gateways have hardware that supports either EU868 or US915, not both. Changing from one US915 FSB to another should work just fine.

Remote code execution on gateways is currently not implemented in The Things Stack.

If you want to get a sense of what’s in the pipeline for future The Things Stack versions, check out the milestones on our GitHub repository. There are also a lot of unplanned issues which we may pick up in future milestones.


Hi Hylke,

Thanks very much for your explanation.

Just to be clear, does this mean when the gateway initially connects, or whenever a message is received from that gateway?

I see that this is not something planned for any particular milestone. Can we assume that this won’t be implemented soon?


Channel configuration is sent when a Basic Station gateway (re)connects to the LNS API. This happens after the gateway is power cycled, and otherwise every 24 hours (depending on the gateway implementation).

We indeed don’t have plans to build a remote code execution feature any time soon, but if this is an important feature for you, you can create an issue on GitHub, and we’ll start collecting :+1:'s from others on it until there is enough demand.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.