I have a generic question about the > ‘Gateway/General Settings/Automatic gateway update’ menue item. There is stated ‘If enabled the gateway will periodically check if updates are available and perform them.’
Question: is it an existing feature only related to TTN Industries gateways or does it belong to a centralized f/w update server who determines the correct f/w by analyzing the gateway of all types? Couldn’t find a hint by using the search engine.
I found a new f/w for one of my RAK gateways and it has NOT automatically updated despite the new f/w is available since begin of December. It’s not a problem to flash the new f/w but on the other hand, auto-update wouldn’t be an uncomfortable feature.
Yes and no, at this point in time it only applies to the first TTI (kickstarter) gateway. Manufacturers of other gateways need to provide their own update mechanism.
BTW, once a gateway is working well there is little to be gained by updating the firmware. Check the release notes if anything pertinent has been updated in the packet forwarder before investing time to update.
Except for testing purposes, I don’t update productive systems unless it’s an urgent safety release. So I disable the checkbox for the time being and decide case by case for the gateways in use.
On the other hand: how would one be notified on a pending update, when automatic update is not enabled?
We’ve seen an update for the security certificates in the past, being quite essential:
(The current Amazon root embedded in the Kickstarter gateway is valid until 31 December 2037. The ISRG root until 4 June 2035. And the DST root is due first, on 30 September 2021. I’ve no idea if all these are used, but that’s irrelevant if the certificate chain for the server changes to use a different root.)
In terms of functionality: Maybe yes.
In terms of of cybersecurity this is a completely dangerous mindset. If there is a known vulnerability in a device, there must be a possibility to fix that in time.
Most bugs in gateways are indeed going to be “bad response to unexpected conditions” types of things, some potentially quite serious, even if the gateway generally functions before the first incident or between them.
Generally speaking, automatic updates should be done by means of a management server for a particular fleet of ownership or design - ie, it’s really not the role of TTN infrastructure.
But gateways put in field locations where they are not easily approached in person should have remote administration capability by their owners or operators, and an ability to push new firmware or apply bug patches is preferably part of that.
Ideally gateways would ship with a capability to point at a manufacturer’s management server, or at a custom installation that the owner can set up based on a repo offered by the manufacturer or their own implementation of a documented scheme.
In reality, people who own gateways in quantity tend to end up rebuilding the entire image from source so that it has exactly what they want, and adding their own remote management system is a key part of that.
It was no offense to you @kersing. Just pinpointing.
Release Notes are an important thing. Maybe the percentage of readers of such things like Release Notes in this forum is a little bit higher than average.
I am also still unsatisfied by the quality of the Kickstarter Gateway. At least there is a mechanism for updating. IMHO only used for bugfixes. Wishes like disabling wifi where never implemented. It seems no one of all the talented embedded software engineers wanted to take care of this hardware. But also another Story.
@htdvisser or @KrishnaIyerEaswaran2, which update does The Things Gateway get when not enabling beta updates? Mine uses 1.0.8, but it has beta updates enabled:
1.0.6 states that “After 8 July 2019, many servers that use Let’s Encrypt will start serving a certificate chain which leads to this new root, and therefore it must be trusted by clients such as the gateway.” But endpoints such as https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870 still use DST Root CA X3, not ISRG Root X1 CA. So I guess even 1.0.5 still works, today?
Expiring root certs for Nodes, GW’s Servers etc., looks to be a looming problem that we should all be aware of and have plans to allow updates for our devices as appropriate A Tsunami of disconnects coming?
The Things Kickstarter Gateway gets its updates from the branch that’s selected in the Account Server. You can find the list of branches here: Branches · TheThingsProducts/gateway · GitHub
The 1.0.6 patch with the ISRG Root X1 has been on the beta channel since May 2019, and on the stable channel since June 2019.
Currently (June 2020):
The stable branch is at 1.0.7 which makes the gateway work with our v3 stack.
The beta branch is at 1.0.8 which makes the gateway work with AWS certificates.
Looks like we only pushed the git tags. In our other repositories our CI marks new Releases, but apparently that’s not the case here. I created the GitHub releases.
Correct. We try to serve the most compatible certificate chain for as long as we can.
A Tsunami of disconnects coming?