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.
I had similar issues but only with 2.4GHz. 5Ghz working flawlessly. What helps me:
1] moving 2.4GHz Wifi card to the slot closest to CPU with heatsink
2] moving 5GHz Wifi card to the farest slot from CPU
3] connecting 5GHz card to duplexer antenas and removing 2.4 Ghz from them
4] connecting 2.4Ghz to separate antena
Now it is working fine. As far as I made some search it has something to do with interference from USB, especially if you use it.
Thats funny. I got USB disk mounted.
And wifi is so bad that I changed it for access points.
just in next room wifi was practicaly not working on 2.4ghz and the house is not even from concrete…
You responded to the thread, which is almost one year old and also in the version, which is end-of-life by us and even by OpenWrt developers.
It is not clear which version of Turris OS do you have. In any case, I suggest checking if you selected the correct country for Wi-Fi networks.
You haven’t said which issues you had with 2.4 GHz Wi-Fi, but currently, my best guess is that it has been caused by interference by other APs near you. These days it is challenging to find a channel, which is not used in 2.4 GHz frequency. It’s good to check Wi-Fi frequencies with a Wi-Fi analyzer. You might want to check this article Wi-Fi coverage and router placement. Did you try to change the channel first? If you are saying about interference from USB, may I ask if you are so sure about that? Did you check it and verify it? Because this is exactly how not correct messages appear. If there was interference, we would change the position of the cards in the factory.
Right now, how did you changed Wi-Fi cards that there could be interference (not verified) from USB 3.0 signals if you put it in the slot, where is the SIM card slot. In some versions of Turris OS, I mean OpenWrt versions, you need to reset the Wi-Fi configuration if you were changing positions. Recently, I was responding here on the forum how you should have connected Wi-Fi cards if you are using an mSATA disk or mini PCIe LTE cards. Link goes to CZ.NIC YT channel.
I had the similar issues mentioned on 2.4GHz. It means it was connected but “No internet connection” . Of course I checked DNS settings, make some measurement and trying other confirgurations, another channels, also reseting Omnia and made another testing. There is no another router nearby I am living in a house. Simply I hope that I tryed every posibilities. Very strange was that there was always good response to “ping” command with different amount of data and no drops. The only solution till I changed the antenas and moved cards on Omnia was to switch off/on wifi on affected devices ( Apple macbook pro 15, 16, samsung galaxy s10) or reboot router. One day I simply tryed another router - TP-Link Archer 750 (openwrt) and it works flawlessy, so I dissasembled Omnia, and move 2.4GHz to another antenas and moved cards and after that no issues. It was also necessary to reconfigure it again. So far I know it works. If it is caused bye some interference - honestly I can’t tell. It is speculation and I apologize for it, anyway the whole moving and changing antenas was inspired simply by reading about such issues on Turris and another devices.
The bad thing on this issu is , that I did not found any way, how to test it , and simulate issues. It is rare ( one or two times per day or less) and I did not found what is causing it… If, so , than there is may be better solution. I know only my steps helps. No software changes at all.
This topic was automatically closed after 31 hours. New replies are no longer allowed.