Turris OS 5.1.5 is in the Testing branch

Community office Testing branches
, ,
#1

Dear Turris users,

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.

3 Likes
Data Collection License Agreement seems stuck
#2

Known bugs:

#4

OpenWrt 19.07.5 changelog, in case anyone else is interested: https://openwrt.org/releases/19.07/notes-19.07.5

#5

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).

#6

It seems that uboot was updated as part of this upgrade. This is really bad:

  • I first lost my boot on /dev/sda1 setting. I have been able to restore it through serial console.
  • Now I have no wifi, lspci show the devices but they are not recognized by the networking part
  • sentinel is not working because certgen is not working crypto-wrapper failed: sn
  • sentinel-dyn-fw-client is not working: ipset v7.3: Error in line 1: Cannot open session to kernel.
  • openvpn is not starting as it complains about /dev/net/tun not being present.

I have restored to a previous schnapps snapshot, switched back to hbs, rebooted numerous time. But my turris Omnia is not working at all.

Any idea how to go back to a working situation?

1 Like
#7

Hi @X-dark,

  • I first lost my boot on /dev/sda1 setting. I have been able to restore it through serial console.

We noticed that this happened during HBL branch that we tested and because of that, we created an issue on our Gitlab to be aware of it: https://gitlab.nic.cz/turris/turris-build/-/issues/217

It was strange though as it happened just once and since that it was not happening. I thought that it should not affect HBK and thus the HBT branch. Unfortunately, it seems slipped through my eyes in upstream changes, because there was cherry-picked support for Turris Omnia 2019 and Turris Omnia 2020 into OpenWrt 19.07: https://github.com/openwrt/openwrt/pull/3647

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.

#8

OK thx.

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.

#9

Mail sent to techsupport.

#10

Replied, even though it seems we have some Christmas elves which affects our support system. :confused: I reported it to guys who are responsible for it. Please disregard multiple messages. It should be just one.

#11

Yes, no problem. I will reply back there but just to let you know I fixed it.

In u-boot env, I forgot to update bootcmd. It was not pointing to scsiboot so this part was never executed and thus the wireless part not initialized.

Everything is back to normal and the only problem was the u-boot configuration overwrite.

3 Likes
#12

Glad that you figured it out and thank you so much for reporting this issue.

1 Like
#13

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

2 Likes
#14

That’s weird, I also have an old Omnia booting from mPCIe, and it didn’t break boot for me. I updated to 5.1.5 about a week ago.

#15

Again current error

#16

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: https://github.com/NLnetLabs/unbound/releases/tag/release-1.13.0

#17

can you also include the openssl that fixes CVE-2020-1971 ?

#18

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)

#19

Caveat: Unbound switched this default to mitigate a CVE… (though I don’t think it’s serious, this part at least)

#20

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.

#21

Yes, it’s still happening.
Sometimes chrome returns an error: ERR_TOO_MANY_RETRIES
But mostly it just reloads over and over again.