We are proud to let you know that we released Turris OS 5.1.5 into the Testing branch. The most interesting change in this release is that we are now based on top of the latest OpenWrt 19.07.5.
Release notes:
Fix for OpenVPN client when filename has multiple dots or dashes
Improvements regarding Data Collection in migration script from Turris OS 3.x
Updated kernel to version 4.14.209
Updated zerotier to version 1.6.2, but it fails to compile for ARMv8, which means that it is not present for Turris MOX (listed in known bugs)
Updated miniupnpd to version 2.2.0
Updated nextdns to version 1.9.4
Updated nano to version 5.4
Updated Knot Resolver to version 5.2.0
Fixed CVEs:
CVE-2020-8037 in tcpdump
CVE-2020-28928 in musl
multiple CVEs in libexif
CVE-2020-28935 in unbound
If you would like to try this release, you need to login to your router via SSH and proceed with this command and after that, your router will be using the Testing branch.
switch-branch hbt
If you want to opt-out from the Testing branch just replace hbt with hbs to be back in the Stable releases.
More details about all branches can be found in our documentation: (https://docs.turris.cz/geek/testing/).
We would appreciate any feedback regarding this release.
MOX classic, WiFi, ,5 GB, simple config, after update and reboot WiFi did’nt work, next 5 reboots hanging, last reboot OK and WiFi works (without any change to config).
I am so sorry for this issue, we are looking into it!
Which Wi-Fi cards are you using? Do you have any logs? Diagnostics would be good!
What certgen says? I need more details about this. Is that Turris Omnia 2020?
We can check it on our end, but we would need the serial number and this is what we get from diagnostics. Also for me, it seems that this could be related to sentinel-dynfw-issues and as well with OpenVPN as it seems that the network part has some issues.
I am using factory Omnia cards (Atheros). I was using the default driver, I tried to switch to cl drivers without any difference.
Certgen error is crypto-wrapper failed: sn.
I am not using Omnia 2020, mine is several years old.
I have disabled OpenVPN.
I will try to send you logs and SN to support email as soon as I find a way to extract the information which is a little complicated as I lost Internet connectivity on my wired LAN as well.
Replied, even though it seems we have some Christmas elves which affects our support system. I reported it to guys who are responsible for it. Please disregard multiple messages. It should be just one.
Today, we are releasing a new RC version of Turris OS 5.1.5. We reverted upstream commit, which erased a U-boot environment for Turris Omnia, so it should be smooth for users, who are using mSATA SSD or any external storage.
There is updated reForis, which fixes SMTP form then you can find updates for unbound, mariadb, and foris-controller-sentinel-module. It fixes the issue described here Data Collection on Turris OS 5.1.4
Note that unbound 1.13.0 seems to deny udp connection by default, potentially spamming your /var/log/messages with those denials. Adding upd-connect: yes is enough to go back to previous behavior. More details here: Release release-1.13.0: Unbound 1.13.0 · NLnetLabs/unbound · GitHub
udp-connect: yes is the new default, so it should be the other way around. It must be the kernel logging these? (slightly surprising to me personally, but maybe Turris has some unusual setting)
It could be related to your U-boot version. We had experience with the old U-boot version so far that it didn’t go well in a large number of cases.
Can you please check if it happens for you again?
I verified it and the fix should be there even though we updated reForis.
We are aware of it even we wrote to the OpenWrt development list regarding the link for OpenSSL Security Advisory, but an update of OpenSSL which fixes it. It is not present in OpenWrt 19.07, yet. I expect that it is going to be cherry-picked from OpenWrt master branch soon. I forgot to mention that OpenSSL comes from OpenWrt as it is, we can prepare a patch where we will update it for Turris routers, but it will delay the update of Turris OS 5.1.5, which we would like to release in upcoming days. Most likely, this is going to be fixed in Turris OS 5.1.6.