We would like to inform you that we released a new beta version of Turris OS 4.0. In this release, there are a few changes. Most noticeable one is that we fixed a issue with Foris, which some of you experienced and reported to us in previous beta version. There are also a security fixes for golang and squid, which we sent to OpenWrt as well.
Full release notes for this release are:
golang: fix for CVE-2018-1687{3,4,5}, CVE-2019-6486
squid: update to version 3.5.28
foris: fix AttributeError password_set
When you are using previous Turris OS 4.0 beta8 release and if you are not using approvals, you should be updated to this version automatically. If you do, there will be waiting for you a notification in Updater tab to approve the update.
If you would like to try this release instead of Turris OS 3.x release on Turris Omnia and start from scratch, you need to download medkit to USB flash drive, which will be formatted on EXT2/3/4. Donāt extract it and plug it to the Turris Omnia router and by using re-flash method (4 LED), it will erase all the data from the current operating system including and write there a new operating system Turris OS 4.0.
Since I had beta8 and no access to Foris and had set to approval needed for update installation I updated to beta9 via ssh and āpkgupdateā and afterwards ārebootā , worked without problems. I have access to Foris again. VPN client with policy based routing also working.
So beta9 doesnāt have any known issues anymore? Just thinkingā¦ if I should migrate to this now same time as I convert my Omnia to use SSD as itās boot media. Beta8 thread just looked pretty bad.
Right, there are still two known issues. Same as in previous beta version.
The first one is specific only for Turris Omnia.
Itās about missing support multi CPU in kernel DSA subsystem. We are waiting for upstream Linux developers to decide what is an appropriate approach to support multiple switch links. There are few patches, but none of them are final and nothing we are going to apply in short terms. There are 2 ethernet controllers on CPU connected to switch but works only one. In the standard setup, it does probably mean nothing. WAN / SFP ports together with all LAN ports are working.
The second one is for Turris 1.0 and Turris 1.1.
We advise anyone, who has Turris 1.0 and Turris 1.1 do not test this release, yet. It is not working.
Iām running 4.0 beta on SSD since beta4 or beta5.
It runs stable.
Only problem I have is with firewall for OpenVPN clients - routing does not work, I had to create script filling iptables with required rules because of bug in fw3 (OpenWRT firewall program).
Today I realized that it is related to the updates.
After each update and night restart the router is dead at the morning. Completely not reachable and LED is off.
Turn off and on the power plug and everything starts fine.
@Pepe If more details needed there exists ticket for different issue but nothign has changes since that time - #004879
Part of your mesasge is related to thread, which was created yesterday - Reboot doesn't work. I will try to respond to your ticket today, which we got in monday afternoon today.
Thanks for reply. I assume VPN issues are with some specific configuration, as there have been also mentions of VPN working. Is it just that VPN clients canāt access āthe interwebsā over VPN connection? Local area access works fine? Did I understand correctly?
Is there any documentation how to config uboot back to use emmc as boot media? If I could just keep 3.x series on emmc, as a backup, in case of fatal failure with beta series.
āOpenVPN clientsā means client instances on my router that connect to some other networks.
That networks are available from router, but not from lan machines. That works only after some tweaks to generated iptables ruleset.
Reverting to mmc You have one post above. Iām running 4.0 from SSD, but also have 3.x on MMC.
Still have issues with connecting with PPPoE to local ISP with VLAN6 on the WAN port to NTU.
Mox classic, this is what foris tells me about the WAN section.
Currently testing forthcoming adblock 3.8.0 with latest beta9 on turris omnia. As soon as I type /etc/init.d/kresd reload (or start/restart) Iāll receive the follwing error:
root@turris:/etc/init.d# /etc/init.d/kresd reload
syntax error. Last token seen: +
Garbled time
culprit is the last test in ārun_instanceā in /etc/init.d/kresd ā¦
Thanks for letting us know. There is created an issue on our Gitlab.
This issue was fixed in one of our Turris OS 3.x release, where is a newer version of Knot Resolver and there was some refactoring, but it didnāt get to Turris OS 4.x release, yet.
But AFAIK it should be harmless. @paja Can we fix that in Turris OS 4.x as well?
I would really like it if the Turris Omnia OS would support GRE tunnel creation/failover properly. Aside from site-to-site tunnels, things like Zscaler (full disclosure: my employer) use GRE tunnels for forwarding traffic to the service.
I managed to get omnia upgraded to 4.0beta9 and SSD at the same time. But rpcd keeps on crashing, forcing me to run service rpcd start to get luci working again. Any ideas why this keeps happening? Or how to debug it?
Luciās fail message is the normal: /usr/lib/lua/luci/dispatcher.lua:230: /etc/config/luci seems to be corrupt, unable to find section 'main'
Also with this fresh install, NextCloud just throws ā503 - Service Not Availableā when trying to navigate to it. No idea where to start debugging.
