Turris OS 5.3.11 is out

Dear Turris users,

We released a new Turris OS 5.3.11 version. This update is pretty huge for a fixup release, so I hope you will like this as much as we do. :slight_smile: Hopefully, each one of you will find something interesting.

Release notes:

This update will be applied automatically for all of our devices unless you are using approvals or delayed updates. In that case, we suggest looking at reForis for further details. If you would find any bugs or regressions, please reach our support department they will gladly help you.


List of known bugs:

Turris HW known bugs:

  • In some cases, Turris MOX and Turris Shield are not correctly rebooted.
    You could try to remove the power supply and plug it back. We are working to have the solution with the manufacturer of SoC (Marvell). In the meantime, you can try this workaround.

Otherwise for each release applies Erratum, which is up-to-date.

Hi Pepe,

About the update, gonna wait until end of next week.

However i have a question about LXC. Will we be receiving a newer version sometime soon?

I believe version 3.0 (version 3.0.3 is currently install on my TO) will reach EOL by june 2023. So we have one year left. However we also haven’t received version 3.0.4 or higher. In the mean time version 5 has been released.

Or is this something we should pursuit ourselves?

1 Like

Is there something interesting why would you want to have version 3.0.4? The last time, I tried that, I was not able to compile it. The CVE, which is fixed there, was backported a long time ago, and it is included since Turris OS since 4.0.1.

However, LXC version 3.0.x has long term support. In OpenWrt 21.02 (Turris OS 6.0 is based on top of it), there is LXC version 4.0.10.

To2016, sentinel FW does not work after auto update, at least not visible on Sentinel view using the given ID/token ? In reforis it says ‘’ all working" . Me think i have to manually restart it ?

edit : after manually restart it in lucy>system>Startup all lis fine. Might have to do with the fact that my ISP is using Dual-Stack Lite (RFC6333), that still gives problems after updates/reboot with the ip4 gateway. Still need to correct that by hand. ( mark off and on )

There wasn’t any change related to the Sentinel, may I ask you to reach our support guy @Stepan by sending diagnostics via our support ticket to take a look at it?

1 Like

Done. ticket nmbr is turris-L1 #xxxxxx7

I noticed now that the Sentinel FW view stopped ( again ) 2 days ago already, so nothing to do with the update.
Now busy with Support about this.

Well that is awesome because that answers my question that we will be getting a newer version with T OS 6.0. Just a matter of time.

After TOS 5.3 will be TOS 5.4, not 6.0.

1 Like

Even though I said in the past, there is not going to be Turris OS 5.4 as we were focusing on kernel 5.15, despite that, things are taking a longer time than expected thus, there is going to be Turris OS 5.4 with a few changes to keep you guys safe and up to date. As I am aware, you are usually interested which things are taking so long. Here is a list for you of things not yet done on kernel 5.15.

  1. Turris SFP
  2. Turris Omnia: LED
  3. VLANs
    We will most likely backport all changes from kernel 5.19 related to DSA and Marvell switches.
  4. Backport patches, which improve PCI controller on Turris Omnia and Turris MOX

me think i found the issue regarding the sentinel FW and the stopping of the data send to the Sentinel URL… i use a smart tv, that i manually Firewalled since that mofo is pinging home like a madman.
As soon as i want to update the tv i uncheck that handmade rule ( save settings ) , en check it afterwards ( save setting ) . After that the Sentinel data send to the Sentinel website stops.
Manually restart all the sentinel stuff to get a readout on the Sentinel URL does not work, a reboot solves it.

If I understand correctly, this is the problem ? HaaS and minipots outages - #12 by JardaB

Firewall changes (deletes and restores) minipost and HaaS rules without warning.- and service restarts do not help?

After testing the activation of the existing port forward rule in the FW, this proxy rule also disappeared for ports 21-23, 25, 80, 587. Externally, the ports are closed.

HaaS recorded records until the last moment
2022-07-30 16:35:00 HKG -

After the router is restarted, the rules will be reset. The error can be replicated. Repeated activation of the existing firewall port forward rules, will break the minipots and HaaS firewall rules … bingo.
I’ve been following this problem with honepots and Haas for a long time but haven’t hit on the cause - thanks to you

1 Like

Well, no CLI wizzard here, just a click click person that likes the TO mucho much. Therefore always trying to figure out what the nOOb user ( me ) is doing, and what the TO does after that :slight_smile:
In this case, yes, this can be easily replicated. Change some custom FW rule, and bingo.

But, what for example happens if you or me restart the whole FW after a modification…does that also solves the probl;em?

Restarting the services

root @ Turris_JB: ~ # /etc/init.d/sentinel-proxy reboot
root @ Turris_JB: ~ # /etc/init.d/sentinel-dynfw-client reboot
root @ Turris_JB: ~ # /etc/init.d/sentinel-minipot reboot
root @ Turris_JB: ~ # /etc/init.d/haas-proxy restart

not help.

Yes, restarting the FW in Luci-System-Startup will remove the problem … similar to /etc/init.d/firewall restart

What I consider the biggest problem is that the indication of the Sentinel function in reForis checks the running of services and not the existing rules in the firewall.

Enabling or disabling an existing port forward rule will reliably trigger the issue.
It is similar to changing reForis - Network - LAN - DHCP deletes the DHCP and DNS settings table Statics Lease :frowning:

Thats good to know, that restarting the FW solves the issue. Since restarting all the seperate Sentinel procc by hand does not solve it here…
So if i make a cron thingie that lets say, restart the complete FW every 24 hours or so, problems are solved?

( meaning this button )

I don’t know … I think it’s completely useless for the average user who still doesn’t change the activation of existing port forward rules.

After all, from my observations, the defective state of HaaS + minipots proxy "corrected itself ?? " after a few days at most. I have never found the fault lasting longer. If I set such a scheduled rule with a period of 1 week, for example.

HaaS not a vital function, but convenient for it to function. It is a pity that there is no true status indication.

Well, with Haas you can manually solve this by making a cron, or by starting Haas manually. I need to do that anyway after a reboot since haas apperantly does not start automatic after a reboot. In reforris it will tell all is fine, while it is not.

But with Sentinel i apprerantly need to reboot to get it working again. But i can try to create the problem ( changing my custom TV rule ) and see what restart FW does?

A firewall restart will reset (renew) the HaaS minipots proxy rules … HaaS restart won’t do anything … now I don’t know if we understand each other.

This topic was automatically closed after 16 days. New replies are no longer allowed.