Turris OS 5.3.6 is out!

Dear Turris community,

It is pleasure to let you know that Turris OS 5.3.6 was released from the Testing branch. This release is based on the latest stable OpenWrt 19.07.9 version.

It brings you multiple fixes for security vulnerabilities, one minor fix for diagnostics script, among updated several packages, including the kernel.

Also, In this release, there was a separate package with English language files for reForis, since it is redundant and impossible to install. These files are already shipped with a standalone reForis package. This was found by one of our users, who experienced such behavior during migration from Turris OS 3.x.

Release notes:

* Based on the latest OpenWrt 19.07.9
* Updated kernel to version 4.14.269
* Updated unbound, fosquitto, foris-forwarder
* Security fixes
  * tcpdump
  * MbedTLS
  * hostapd
  * wolfSSL
  * expat

This update is going to be downloaded and applied automatically. If you are using delayed updates or approvals, please check reForis for further details.

We appreciate any feedback regarding this release. If you experience any regression or bugs, please let us know in appropriate ways.


Great, now any ETA for TOS6 yet? Just asking because the ath10k radio is becoming irritable and I am strongly considering testing/switching to the asia rf AX alternative, but that deopends on TOS6 IIRC?


Unfortunately, we discovered several issues with DSA and, together with VLANs on OpenWrt 21.02.x series, we are not able to proceed with network migration successfully for everyone. Some of you might end up with broken Internet. :frowning:

And that’s why there is no Turris OS 6.0 so far.


Am I right to assume that this mostly affects networks that configured advanced VLAN usage on the switch/LAN ports? Since I only use VLANs on eth2 for WAN, do I need to prepare for big issues when switching to TOS6? (Having configured DSA on a different router I feel the pain, yes DSA clearly is the only available way forward for OpenWrt, but we are still a bit in the rough in the conversion; and the defaults are not as helpful as they should be*).

*) I think that OpenWrt should default to using a VLAN with bridge-vlan-filtering on br-lan, as otherwise anybody splitting up br-lan into different VLANs will run into the issue of loosing access to br-lan when committing the change. But this is probably not the right forum to whine about OpenWrt :wink:


I configured automatic updates with approval.
I configured “Automatic Restarts After Software Update”-delay to 3 days.

I expected the usual “restart is needed” notification. (And automatic restart after 3 days.)

But my Omnia just restarted immediately without any warning.

PS: Thanks for information about TOS6.

Yes, you are right.


This usage doesn’t invoke DSA. DSA is only invoked when VLAN-traffic is transported between switch-ports without passing the CPU - your internet-traffic passes your firewall and your sqm…

1 Like

Could be that only network was restarted? I lost connection to my lxc container, but uptime is 33 days and running kernel is still the previous one.

root@turris:~# uname -a
Linux turris 4.14.264 #0 SMP Tue Feb 8 00:42:25 2022 armv7l GNU/Linux

root@turris:~# uptime
21:34:17 up 33 days,  1:31,  load average: 0.07, 0.13, 0.21

Omnia with LXC and MWAN3 (for load balancing two lines) and MOX with LXC went smooth. No problems. Everything was up again. Only Problem: MOX needed a power cycle to reboot.For me it is not a real problem. The MOX allready has reboot-issue-workaround-v4.

Just collision info … I removed tcpdump-mini

Updater failed: 
[string "transaction"]:327: [string "transaction"]:151: Collisions:
• /usr/sbin/tcpdump: tcpdump-mini (existing-file), tcpdump (new-file)

MOX classic 512 MB, simple config, branch HBS, after upgrade to 5.3.6 LED config section in LuCI empty, even though there was an entry for RED heartbeat LED before.

EDIT: moreover, cron table for root disappeared as well :frowning:

From your post, it is not clear to me if it was solved by removing tcpdump-mini or not.

  • If not, feel free to reach our customer service department.
  • If yes, then this issue was already mentioned here.

Upgrade TO 1GB 5.3.5 to 5.3.6 worked without issues.

I’ve also lost connectivity to my LXC containers after update has been installed, but after a reboot LXC containers are working fine.

At that time, I was returning to an older image, other update processes were underway - the last mentioned error message was announced today at 9:07 AM.

Yes, I didn’t search the forum, I have to improve. The last mention of this error was in November 2021 … Tcpdump updater error. For me, the problem manifested itself only now in the course - 6 alerts during 22-23. March.

Every update from version 5.3.6, follectd is installed and … weeds syslog of a lot of records
collectd [32747]: Available write targets :: [none]
I always have to retry uninstall follectd

Otherwise, the syslog has been nicely cleaned of permanent unnecessary errors :slight_smile:

No, at least on omnia, switch configuration is broken from factory: Omnia + TOS 6.0 (HBL): Switch configuration broken (#336) · Issues · Turris / Turris OS / Turris Build · GitLab

In one direction, it kind of works as a hub, not switch, right now (with all performance implications)…

MOX A+D TOS 5.3.5 smooth upgrade.
Approval is enable, when I approved the upgrade it rebored right away, without prompting, did you change that behaviour?

However, this was the first time since TOS 5.2.0? I did not need to unplugg power to get it up again. Nice!

(No fw reboot workaround installed)

This does not look good. Should I do something about this?

I double checked that, uptime was reset to zero, new kernel running. In my case Omnia rebooted immediately without any warning. Also notification just contained the change-log, without any further information, no “installation was succesfull”, just the plain list as present in the first post.

Same experiance with my MOX