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
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?
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…
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.
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.
Thanks to the team for all the hard work.
By default, the omnia comes with an ath9k card for 2.4ghz. ath10k makes no difference there.
The normal ath10k driver is worthless for WPA3 as it does not support 802.11w with the QCA9880. Only for the QCA99xx chips. CT supports 802.11w with both.