Turris OS 6.4.3 is released!

Community office
, , ,
1

Dear Turris users,

we just released Turris OS 6.4.3. There are several security updates and bugfixes as usual, but there is also a little bit of new behavior.

Over the time, we have been enhancing support for various LTE cards and we plan to continue doing so. This release will actually automatically configure any LTE card it finds if there is no PIN required. Hope you will find that useful.

We are also testing a new alternative client for our Dynamic Firewall. You can enable it in package lists.

As always, we appreciate any feedback and how are the new features working for you. Full release notes follow.

:rocket: New Features
• dynfw: New experimental client
• drivers: More packages are automatically installed based on devices present
• drivers: Automatic setup of supported 3/4/5G with PIN-less SIM

:pushpin: Updates
• kernel: update to version 5.10.194 and 5.15.130
• curl: update to version 8.3.0
• openssl: update to version 1.1.1w
• wget: update to version 1.21.4
• php8-pecl-sodium replaced with php8-mod-sodium
• msmtp: update to version 1.8.24
• omnia-mcutool: updated to version 0.2 and packaged firmware

:bug: Bug Fixes
• switch-branch: reinstall all packages when switching between branches
• schnapps: fix regexp for ssh uri
• foris-storage-plugin: explicitly add more dependencies
• resolver-conf: fix calling of script to fill entries from DHCP
• resolver-conf: fix superfluous reloads on some IPv6 networks

8 Likes
3

After disabling original dynamic firewall client and enabling experimental one in Packages, reForis displays on Overview page that Dynamic Firewall is Disabled.

Turris 1.1

4

So is it advised to run omnia-mcutool --upgrade now?

5

I am curious, how do you keep the packages up to date. Do you use renovate or something like that on gitlab to automatically create pull requests with security fixes or new versions ?

6

Hey, I’m glad that you are asking this question. :slight_smile:

To be honest, most of the updates (I mean really only updates section), which you can see in OP’s post were made by me, actually. Not only Turris, but also OpenWrt can benefit from it. That’s the open-source spirit, which I like and am somehow proud of. I hope they fulfill my wish I had and wrote here publicly to be part of the OpenWrt core team. It’s never late to give up.

Turris, or neither do I use anything automated. This is all boring stuff, which is made manually by hand.

We (ehm, I am not working anymore for Turris, never mind) let me correct myself. If packages are upstreamed or rather are included in OpenWrt feeds (base, packages, routing, etc.), you get email notifications weekly if you are maintainer of the package (= PKG_MAINTAINER in Makefile) that there is a new release. While talking about this, this is the service that handles it: OpenWrt/Upstream Versions (Turris guys do have something similar, but not used these days…) That’s one way you can get at least some notification. If you are bored enough, you can go through various mailing lists or look at upstream (in this case, OpenWrt), if the package was updated.

Steps:
This leads that you need to manually edit the package Makefile, compile it locally or remotely (if you have some machine there (server, VPS, etc.)), then upload it by using scp to your router, test it that it works, if yes, copy/move or do the same changes in the upstream repository (not the build repository even though it is also possible) and push it. Once you pushed it there, let’s hope that you did not break anything while running full build. What is very useful in upstream is that they do have at least test.sh files, some kind of run testing inside a container. The file checks that the package does not segfault and returns at least the version.

To sum it up, this release Turrris OS 6.4.3 contains more changes than it is advertised, so some things can be broken, sorry for that. Hopefully, they don’t, but Turris released it so fast, so let’s see.
You know, the previous release was done more than one month ago and I wanted to get rid of some things which are either deprecated or it deserve to be fixed (CVEs, …). Maybe it took longer the guys working at Turris do not contribute upstream anymore, and I was faster in upstream, who knows. I was getting ignored even I gave a few hints to them via GitLab, but yeah. Upstream is the way I could get something included in Turris.

If we go through the details:

We can discuss if those things were really required to be included in the branch, which is end-of-life, but you know what… I wanted to have Turris routers secured. Hope you don’t mind.

Sorry that it is too long, I had a few minutes to write this up. :smiley:

7 Likes
7

Hi,

we don’t have anything automated to bump packages, we experimented with something in the past, but in the end it was more work to get it working and to fix errors then to do work manually. We follow various security advisories mailing list and in general we work together with upstream to help each other. Unfortunately, nowadays we depend on upstream version that is no longer maintained upstream (at least officially), so we are on our own.

Our main focus nowadays is to migrate to newer version, but at the same time, we are making sure to keep the current release up to date with all relevant security fixes. At the same time we continue to bring you new features.

And sometimes we have to fix conflicts and breakage that arise from occasional updates to the upstream repo despite it being out of maintenance that are quite often changing the same packages as we are fixing in our repositories.

2 Likes
8

Any information/estimates in that regard? Not trying to be annoying, just curious.

9

That is the idea. We will write up something about it in few days with a short howto.

10

Don’t want to rush it, but it looks quite good nowadays, so I hope soon. Not sure if we will manage in October, but I have my fingers crossed for November :wink:

4 Likes
11

TO 2016, HBS branch, 2 GB, 2x WiFi, HaaS, RIPE Atlas, Sentinel, lxc, SSD (logs etc), simple config, all seems OK - except one warning during update:

WARN:Request not satisfied to install package: sentinel-dynfw-client

12

@Pepe @miska

If i may offer some advice, small automation goes a long way. I would recommend trying renovate with config for security patches only on single repo where you have some tests.
I work as security engineer and for classic apps / web apps this works well enough. Automating the boring part of the work, where there is no decision to be made. I dont know if i your case it is just to find versions of the packages to be updated and convert that into pull requests, so you dont have to read all the mailing lists. Starting small and targeting security only packages with low risk of breaking anything would be my approach.

I feel your pain, patching stuff manually is boring work with low reward and without any automation almost impossible to get on top of for any large project. Number of packages grow every year and without repeatable steps and good testable workflows this can swamp anyone and will likely only get worse in the future.
I dont want to sound like a smart-ass as i have limited knowledge of your environment, just to point out i believe there is a better way of doing this.

13

We know there is a lot that can be in theory automated, but we can’t just stop pushing updates and spend a year automating it :slight_smile: The tool we used in the past wasn’t helping that much, but maybe we will find something better in the future. As I said, our current focus is migrating to the upstream supported distribution so we can better share the burden and improving our automatic tests. Following the security lists and bumping the versions is actually the easier part. The more time consuming and boring part is actually testing that the update doesn’t break anything.

2 Likes
14

It’s probably a bug. Thanks for reporting.

15

Yes, this is what I am saying all the time in upstream. Should we care about quantity over quality or quality over quantity? Dozens of packages are already not maintained (in OpenWrt and also by upstream developers). What should we do with them? Remove them, because usually they are used by a few people. Thus, it is a pity, but that’s life. :sweat_smile:

But also, if I look at numbers, I don’t like when people are called numbers, so try once again. Honestly, if you look at OpenWrt or even Turris community, you can look that it does not grow in terms of maintainers, or developers. It is quite the opposite. People are moving to different things, etc. Currently, involved people suffer lack of motivation, so it is hard to do anything about that. Ideas are, but there is no time to do that as always.

16

Could you maybe also add a short explanation what the MCU actually is and does? I guess it is the microcontroller responsible for controlling and booting the main CPU? Or is there anything else it does (I also was LEDs are maybe connected to it).

17

Spot on! It is responsible for booting the whole board in correct order and for handling the buttons and LEDs.

18

I was more under the impression that the Turris project is following a producer/consumer model (which is fine) where most of the community interaction focuses on user support and less on development.

To me it’s unclear to what extent the Turris team is interested in external contributions beyond testing feedback and occasional one-liners to fix small issues. E.g., the open issues for TOS 7 look manageable (at least for Omnia) but is the information on GitLab somewhat reliable in terms of what’s open/fixed/being worked on?

19

Thanks for the update. However, I have experienced a) a rather annoying bug and b) some undesired behavior with the recent upgrade.

Regarding the bug:
During the upgrade, my wan and wan6 devices were removed from the firewall zone ‘wan’. Rather annoying if your network does suddenly not work anymore, took me a bit to figure out.
Manually added it through Luci again, works fine again (after 5min of testing).

Regarding the undesired behavior:
My 3G modem was already configured, so automatically adding the GSM network device is not wanted on my end (despite all good intentions from your end :)). Would be better to check for an existing device or rather offer a wizard that folks can trigger manually.

20

I started getting error messages from the updater failing yesterday that I think is related to this release. I’m on 6.4.2 and the error message is:

Subject: Notification from your router turris

Error notifications
===================
Updater execution failed:
inconsistent: Requested package mcutool that is not available."