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. Hopefully, each one of you will find something interesting.
Release notes:
Updated kernel to version 4.14.287
Updated Knot Resolver to version 5.5.1
Updated unbound to version 1.16.1
Updated syslog-ng to version 3.37.1
Updated bird2 to version 2.0.10
Updated bind to version 9.16.30
Updated wireguard to version 1.0.20220627
Dropped moonjit in favor of upstream luajit package
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.
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.
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.
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?
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.
Turris SFP
Turris Omnia: LED
VLANs
We will most likely backport all changes from kernel 5.19 related to DSA and Marvell switches.
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.
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 - 218.250.190.178
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
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
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?
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
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?
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?
Hopefully, each one of you will find something interesting.
