Turris OS 4.0.6 is released into HBT branch

Dear Turris users,

We released a Turris OS 4.0.6 into HBT (Testing) branch. This release contains fixes for security vulnerabilities, which were found in mbedtls and tiff, bug fixes for updater and avrdude and improvements for zerotier and updated kernel.

Changelog for this release:

  • updater: fix packages provides and modify virtual packages behavior
  • kernel: updated to version 4.14.167
  • zerotier: add /etc/config/zerotier as configuration file
  • avrdude: fix GPIO path building
  • mbedtls: updated to version 2.16.4
    Fixes: CVE-2019-18222
  • tiff: updated to version 4.1.0
    Fixes: CVE-2019-14973, CVE-2019-17546, CVE-2019-7663, CVE-2019-6128

If you would like to use the testing branch and provide us feedback, please follow our documentation, where you can find details about how you can switch back to the stable branch in any case.

Any feedback is appreciated.


MOX: reboot works (two devices), reForis works, Managed devices (client for TOS 3.11.13) works.


There seems to be some problem with memory… or probably there is some problem with number of files in TMP folder… and it says something about memory error …

After update Foris works, Luci works, Reforis doesn’t work - there is something about Python error…

Reboot from command line seems to be working.
Turris Mox Classic, HBT branch


MOX clasic, very simple config, WiFi, seems working :wink:

Is there any news yet?


I finally ordered 64GB Samsung EVO Plus SD card with intention to migrate my Turris 1x to this release.

I will do backup of current SD Card frst with dd if=/ dev/mmcblk0 of=/dev/sda (where mmcblk0 is original SD card in turris and sda new SD card in card reader connected to USB in turris) then I will replace cards physically and have backup in case unsuccessfull migration so I can quickly restore system back.

Once cards exchanged I will import turri1x medkit to factory as described in 4.0.3 and then restore all services one by one with more less fresh installation. My big question is LXC containers where i got powerpcspe jessie debian containes with a lot of stuff and pihole. Will it be enought to just restore /srv/lxc rootfs from snapshots and reconfigure lxc-auto and restart containers on new system or anything else is necessary. Any advice what to take cere of and take into consideration and what is supposed not to work after this manual migration from TOS 3 to TOS 4 ?

Also want to use okgscript.sh for package migration https://forum.openwrt.org/t/script-to-list-installed-packages-for-simplifying-sysupgrade/7188/2

Which brang team can recommend to be most stable HBT ? HBS ? HBD ? Or is it safe to go for TO5 devel on Turris1x ?

We are not in a position to release Turris OS 4.0.6 to the stable branch, I’m sorry, but if anything happens in this release, we are not able to fix it in next release. OpenWrt developers had a good idea to backport security patches for libubox/ubus, which mostly fixes CVE-2020-7248, but I was not able to reproduce it on OpenWrt version 18.06, but only in OpenWrt 19.07 and OpenWrt master. However, it breaks procd functionality for us in OpenWrt 18.06. There was a similar issue in OpenWrt 19.07+, but it was reported by me and further fixed by OpenWrt devs.

So, any services starting with procd does not work and you need to start it manually and then it works. I’m talking about services like transmission, fosquitto, i2pd are not starting with procd. It requires further investigation and we are focusing to bring you Turris OS 5.x.x. release.

Our issue on Gitlab, where you can find also a link, where I reported it to OpenWrt devs:


Great! Turris OS 5 is coming.

Means there will be no more updates in the 4.x branch after 4.0.5? An update to 5.x instead?
Would this be easier than from 3.x to 4.0 back then?

Best regards

I can’t promise anything, but for now, it looks like it, but I may be wrong as anything can change. Yes, this is going to be a lot easier from 4.x to 5.x than from 3.x to 4.x. No need to use a re-flash method. It will be handled automatically via updates. Even now, you can try switch-branch to branch hbl, where you can find a development version of Turris OS 5.x.


Any chances this can be backported to current release? This blocks me from installing strongswan-full:

We would like to release it as this was fixed really fast, but this can not be done very easily. You may check our workflow, but what I can suggest you, for, now is to try to use switch-branch hbt, where it is fixed for you. You can check other branches as well, but I wouldn’t use HBK branch due to issues, which I described in my previous posts.

In the future, we would like to do releases more often.

When will the ath10k crashes be solved? I see that it has been an issue with Turris OS 4 for a while. I’m running TurrisOS 4.0.5 ab9d1bf on a Turris Omnia, and the 5ghz network crashes consistently every 3 days or so.

You could try ct-htt driver as workaround. My 5Ghz Wifi is stable since I switched to it and other users seem to get good results with it, too…

See: Kernel module crashed

1 Like

Thanks @protree, while I appreciate that there is a workaround for the crashes, I really don’t understand why this has not been fixed in Turris OS?

The reason is that from our testing ct-htt drivers there are some problems with some of the Omnias. While non ct drivers seem to not behave well in some circumstances (possibly areas with high signal noise). We are planning on allowing users to switch optionally between ct and non-ct variant but that are just plans for now.

1 Like