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.
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 ā¦
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 ?
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:
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.
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.
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.
We have been installing Turris Omnias for customers for years, but recently we received several reports of Wi-Fi issues.
These issues have forced us to replace several Omnias in production with closed source hardware and also to suspend all Turris installs until the issues can be resolved.
Our experience with the Turris Wi-Fi over timeā¦
3.x (early versions) - industry leading reliability with no connectivity failures on any band
3.x (more recent versions) + 4.x (more recent versions) - frequent 5GHz connectivity failures
4.x (latest version) - no 5Ghz connectivity failures (which is great!) but frequent 2GHz connectivity failures
When the connectivity failures occur the Wi-Fi status indicator on the endpoint will still show as āConnectedā but with a status of āno Internetā.
While in this state attempts to ping the Omnia will return a result of āunreachableā.
Disconnecting then reconnecting will briefly allow traffic to flow again, but the failure quickly returns.
Power cycling the Omnia will resolve the issue for a day or so, then the failure returns.
I tested numerous Omnias before identifying these issues were software related rather than hardware failures.
The issue is similar to this:
After some research I manually switched an Omnia running 4.0.5 to the Candela Technologies Wi-Fi driver with the terminal commands shared by āTazā here:
The result was an immediate improvement in 2GHz stability.
Since making this change the experience is comparable to the early versions of 3.x where Wi-Fi was incredibly reliable.
This experience is corroborated by several other users recently here:
We also spotted the feature request to allow users to manually switch via the web interface rather than via terminal commands:
All of this leads to some questionsā¦
1 - was the early 3.x firmware using the Candela Technologies Wi-Fi driver and was this changed at some point to the OEM Wi-Fi driver?
2 - will automatic updates (for example 4.0.5 ā 4.0.6) revert a Turris manually configured with the the Candela Technologies Wi-Fi driver back to the OEM Wi-Fi driver?
3 - why is the project not shipping the Candela Technologies Wi-Fi driver by default if it is so much more reliable?
I also identified that the early 3.x medkit we used to prep the Omnias defaulted the auto update feature to off.
Customers that received those Omnias have not reported any Wi-Fi issues, but it is because they were not auto updating as expected.
While this is bad since they are not receiving updates, at least the Wi-Fi is stable until a manual upgrade to Turris OS can be completed.
As poster āmh182ā mentioned here āA wireless router with unstable wireless connection is like a car without an engineā!
Our request is for the team to make restoring Wi-Fi stability the top priority.
Over time the project has decided to add many ābells and whistlesā but nothing is more important to our shared customers than Wi-Fi reliability and performance.
Thanks to everyone with the Turris team.
We look forward to hearing a status update on Wi-Fi stability that will allow us to resume Turris installs for customers.
We are also hopeful that the project can converge on a stable build of Turris OS 5.x OpenWrt 19.07 and the legacy 3.x and 4.x branches can be retired.
No. We tried to do switch to CT drivers with Turris OS 3.4 actually and after huge issues we reverted to standard drivers with TOS 3.5.
Depends on how configuration was made. If it was correctly specified to updaterās config then it is going to survive. It is intended behavior of updater. In reality update rather fails If in any future CT drivers are going to be unavailable if correctly configured. (I think that command suggested by Taz is correct in this sense)
Because they are not. Our experience is that depending on load they can be less stable but faster. Second problem is that with initial revision of Omnia the wifi cards used were outside of PCI parameters and CT drivers are more affected by that. That means pretty much no functionality.
That means that we wonāt switch to CT drivers on Omnias at the moment. Turris Mox is shipped with CT drivers out of the box (although we have more reports about unstable wifi on Mox than Omnia now).
The current state is that development of non-CT is pretty much stale. Compared to CT drivers, those are now under heavy development. This means that they are probably going to be better than non-CT drivers. We are thinking about switching but after fiasco three year ago we are careful and let users choose rather just flipping. Note that from our end we still have more reports about WiFi unstability on Mox than Omnia. This means in broad strokes (ignoring that Mox is newer platform so more reports overal) that CT drivers are not yet ideal.
Thanks for the reply and the clarifications - these are helpful.
After further testing the 2Ghz Wi-Fi disconnections eventually returned on Black model Omnia I was testing on even with the CT drivers.
There is some minor configuration of Wi-Fi in effect (specify Channel Static vs Auto, etc) but not anything I would expect to cause reliability issues. Iāll continue testing and share exact configs and logs if issues continue.
In order to remove possible failing hardware from the test I unboxed and prepped a Silver model Omnia today with HBS 4.0.6 then upgraded to HBL 5.0.0 using the switch-branch command.
Previous attempts to install via medkit direct to HBD 5.0.0 have resulted in an Omnia that powers up but fails to provide an IP Address via DHCP.
Iāll do some testing with the vanilla Wi-Fi drivers on the HBL 5.0.0 build for comparison then share the results.
