Turris OS 3.11.16 is released

Dear Turris users,

We released a new Turris OS version 3.11.16 to you. There are security fixes for vulnerabilities, which were found in tor and subversion packages. We updated several packages like msmtp which was requested here on the forum.

Changes in this release:
• tor, subversion: security update
• msmtp, curl, atlas-sw-probe, reptyr, btrfs-progs, nextcloud, youtube-dl, netdata, netmetr: update

When you are using Turris OS 3.x version, you should be updated to this version automatically. When you are using approvals, you can find a notification in the Updater tab.

If you will find any issues, please don’t hesitate and send an email to our Technical support department.

Enjoy the release.

One of my turris routers just sent me a notification that updater failed because of readonly filesystem… So I went to check what’s going on, and my NAS drive used in storage plugin reported many BTRFS filesystem errors. Before, it was ok. The router cannot even boot now.

I’m not sure it’s connected with this update, but the timing would suggest so…

These are the errors:

btrfs_dev_stat_print_on_error: 66 callbacks suppressed
BTRFS error (device sda1): bdev /dev/sdb1 errs: wr 29, rd 1115991, flush 0, corrupt 0, gen 0

Your eMMC flash is destroyed.

/dev/sdb is IMO the NAS…

1 Like

Fine update! i do notice a faster (+ 15 % ) download-speed, or is that just me?
oh, and i lost ‘mount points’ in luci, and storage in forris. Strange.

Edit : ok, solved it by activating NAS in Forris, now ‘mount points’ is back.

Updated from TOS v.3.11.14.
After reboot DHCP is not working anymore, therefore I cannot test my other services (tor, VLAN-separated iot- and guest-networks), dyndns is working. Since I cannot assing permanent IP on my company-laptop (no admin-rights) and have no time to troubleshoot (quick things like another reboot, /etc/init.d/dnsmasq restart or /etc/init.d/resolver restart didn’t help), I need to rollback to working snapshot.

Since this update msmtp is misbehaving (unable to login to smtps/submission), the server always states Apr 18 00:40:04 mailserver postfix/smtps/smtpd[19635]: warning: redacted.dip0.t-ipconnect.de[]: SASL PLAIN authentication failed: resulting in my home IP getting banned by fail2ban.

@jhuebner Can you please double check your credentials provided to msmtp? The latest version is using GnuTLS instead of OpenSSL code, which is no longer maintained in msmtp. Configuration remains identical and it supports more features like TLS SNI, OAUTHBEATER authentication and so on. Isn’t there a possibility that something on the smtp server was something changed?

May I ask you if you are using ppp? In Turris OS 3.11.15, we backported patches for security vulnerabilities for it. There was updated unbound, which is not default resolver on Turris Omnia. And in this release, there was not anything related to DNS/DHCP. Those changes should be included in the next release, which we are preparing and it will be in RC for a week or two. Because many people are these days working from their homes, we need to be sure that we don’t want to break something. But many of them are already included in Turris OS 5.0, which is in the current testing stage.

Do you mind sharing any logs to see what’s going wrong in your case? I am not sure what could be the culprit.

Would you please share output of command mount? It will shows us if the filesystem on eMMC is read-only or not and then we can proceed further.

I’m not saying the CVE should be ignored… but using a git credential helper on Turris would feel a bit weird to me.

Thanks for your reply. I also happen to be the administrator of said mailserver. I don’t touch its configuration very often, and am quite confident that nothing changed on that side (maybe the occasional postfix updates from the package manager, but nothing out of the ordinary). But I’ll double-check (reset password to a new value on both sides etc.) and will report in later.

Okay, I now retrieved the logs from the dead router stored on an HDD, and it seems the internal MMC started exhibiting BTRFS errors on March 29, so it probably wasn’t caused by this update…

Although the very very last logline the router has written is from April 3:

08:59:37 info updater-supervisor[]: Running pkgupdate

But still, this router was set to run on stable releases, so the pkgupdate probably found nothing, and it just means that at that time even the BTRFS driver for the HDD got corrupted. When I now connected the HDD to a computer, the filesystem seems good, though… So probably just an in-memory corruption of the driver after living for a few days on a corrupt system partition…

Can we expect to see https://www.root.cz/zpravicky/cloudflare-spustilo-dns-s-filtrovanim-nebezpecneho-a-nepristupneho-obsahu/

for english speakers: https://lifehacker.com/block-malware-with-cloudflares-new-dns-options-1842646761

implemented in future release?

1 Like

Create own DNS forwarder rule.

For example modify /etc/resolver/dns_servers/99_cloudflare.conf file.

will it persist through releases, will it persist through migration from v3 to v5?

Why not, it’s your own file. And if not, you can copy it to right directory again.

1 Like