Turris OS 5.2 is released!

Pepe · May 27, 2021, 8:07am

Fixed, thank you for reporting!

pete · May 27, 2021, 8:36am

Thanks for the reply @Pepe

The thing is that the downtime was not seconds, but minutes:

Not sure if the network reload has to happen immediately after the update was performed. Would it be a problem if the reload does not happen until the reboot (which I am able to schedule to 3.30 AM).

In the meantime (until the update window feature is implemented), would you recommend turning off automatic updates or enable manual approvals instead to mitigate this issue?

on an unrelated note: I am unable to login to haas.nic.cz (502) and reForis says the haas token is invalid:

bruteforce · May 27, 2021, 8:50am

Hi, thanks for the answer. You are right - I just slighly changed configuration at kresd listening addresses part and it came back. So all good and thank you for the update - you did a great job!

cynerd · May 27, 2021, 8:56am

Network reload is required because we can’t simply decide if services are in a consistent state after the update. The solution is to just reload them when they update to make sure they cooperate with each other as expected. This includes network services and thus it must result in network dropout. The solution is scheduling updates to the time window, as already stated here, not to not reload services. For time being update approvals can fix it for you. Make sure that you approve updates regularly to get all fixes as soon as possible.

The inability to set HaaS token and login is probably unrelated. Thank you for noticing that there is some issue with the haas login. It was passed to the relevant team. Can you please in secrecy (using private messages here) send me your HaaS token so I can pass it to our frontend developers. It seems that verification on input field might not be correct.

iron-maiden · May 27, 2021, 11:51am

Thank you Turris team for the great work.

Country CZ, got update yesterday(26.5.2021) around 17:30 by local time, actually I even didn’t notice getting update until I had wifi outage for about 30s, then when I checked the router I found 5.2.

Everything works fine, no issues so far.

Happy Omnia 2020 owner

Slaveck · May 27, 2021, 12:09pm

Hi, Upgrade of Turris Omnia and Turris 1.x went more less fine, just few minor issues:

I’m running on both routers the Atlas probe. After upgrade I see in Packages the Atlas probes is not checked and seems as not installed but in reality it is.
On Turris 1.x in Interfaces I cannot see interface settings at all, there are messages like There are no interfaces in this group or You have to assign at least one interface to this group
In NetMetr if the ping is less than 1ms, the GUI shows N/A

image1013×93 6.65 KB
On Omnia router I had CZ language by default, after upgrade some of the texts were mixed with English on the same page. So I removed CZ language completely and now OK (obviously)

Anyway, good work and thanks for all your effort!

cynerd · May 27, 2021, 2:42pm

Package lists are a list of packages not installation of selected packages. You can have packages from the package list installed without having the package list selected. We do not automatically enable package list because you already have those packages installed. Its purpose is to allow easy installation for those who do not have it yet.
This is known and worked on (https://gitlab.nic.cz/turris/turrishw/-/merge_requests/7).
Known but low priority issue
Czech language like any other language is community translated. See https://docs.turris.cz/geek/contributing/translation/

fantomas · May 27, 2021, 4:13pm

did you measure since down to up? Because if you measure every 5 minutes, one missing interval can look as 10 minutes outage

pete · May 27, 2021, 6:02pm

Collectd interval is set to 30 seconds…

dmth · May 27, 2021, 10:30pm

Was there a subtile change in how “Local DNS Domains” are interpreted? I have noticed different behaviour of DNS between 5.1.x and 5.2. I shared my thoughts in this thread: Change in DNS Behaviour between Turris 5.2 and 5.1.x
Edit2: Aforementioned problem has vanished…

Edit1: Oh I really forgot to thank you for this release. It looks great so far, I really look forward on working with the new storage module.

pete · May 28, 2021, 9:41am

This morning, syslog is filled with haas-proxy errors:

May 28 09:08:19 turris haas-proxy-start[8336]: 2021-05-28T11:08:19 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed'
May 28 09:09:01 turris crond[30639]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
May 28 09:09:19 turris haas-proxy-start[8336]: 2021-05-28T11:09:19 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed'
May 28 09:10:01 turris crond[30749]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
May 28 09:10:01 turris crond[30750]: (root) CMD (/usr/bin/notifier)
May 28 09:10:01 turris crond[30748]: (root) CMDOUT (There is no message to send.)
May 28 09:10:19 turris haas-proxy-start[8336]: 2021-05-28T11:10:19 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed'
May 28 09:10:58 turris haas-proxy-start[8336]: 2021-05-28T11:10:58 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed'
May 28 09:11:01 turris crond[30899]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
May 28 09:11:08 turris haas-proxy-start[8336]: 2021-05-28T11:11:08 CRITICAL twisted Unhandled Error
May 28 09:11:08 turris haas-proxy-start[8336]: Traceback (most recent call last):
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/internet/tcp.py", line 243, in doRead
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/internet/tcp.py", line 249, in _dataReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py", line 703, in dataReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py", line 728, in dispatchMessage
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]: --- <exception caught here> ---
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/log.py", line 103, in callWithLogger
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/log.py", line 86, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/context.py", line 122, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/context.py", line 85, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/service.py", line 45, in packetReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/connection.py", line 295, in ssh_CHANNEL_EOF
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]: builtins.KeyError: 0
May 28 09:11:08 turris haas-proxy-start[8336]: 
May 28 09:11:08 turris haas-proxy-start[8336]: 2021-05-28T11:11:08 CRITICAL twisted Unhandled Error
May 28 09:11:08 turris haas-proxy-start[8336]: Traceback (most recent call last):
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/internet/tcp.py", line 243, in doRead
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/internet/tcp.py", line 249, in _dataReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py", line 703, in dataReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py", line 728, in dispatchMessage
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]: --- <exception caught here> ---
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/log.py", line 103, in callWithLogger
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/log.py", line 86, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/context.py", line 122, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/python/context.py", line 85, in callWithContext
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/service.py", line 45, in packetReceived
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]:   File "/usr/lib/python3.7/site-packages/twisted/conch/ssh/connection.py", line 308, in ssh_CHANNEL_CLOSE
May 28 09:11:08 turris haas-proxy-start[8336]:     
May 28 09:11:08 turris haas-proxy-start[8336]: builtins.KeyError: 0
May 28 09:11:08 turris haas-proxy-start[8336]:

ekim · May 28, 2021, 9:32pm

I dont have an IPv6 address anymore after upgrading to 5.2.

],
“ipv6-address”: [

    ],
    "ipv6-prefix": [

    ],
    "ipv6-prefix-assignment": [

    ],

outbacker · May 28, 2021, 11:28pm

I’ve got a serious issue with 5ghz wifi on 5.2

Device: Turris Omnia from Indiegogo
History: Clean flashed 5.1 three days ago, setup 5ghz wifi with default settings apart from wifi name and password (channel auto, mode ac 80mhz). It decided to use channel 36.

A few hours later I was pleasently surprised by the 5.2 update.

Today I tried to set a fixed channel as I noticed some congestion on the automatically chosen one.
That’s where the problems began. The 5ghz wifi module didn’t come back up after saving the settings, not even after 10 minutes.
So I switching wifi 1 off and on again, to no avail. A reboot didn’t help either.

What did bring it back to live temporarily was clicking on the yellow notification to reload the default settings as wifi modules might be switched (I guess it was supposed for users upgrading from 3.x, but whatever).

However the problem generally remains. It seems that it wasn’t the channel change I did, as “ac 20mhz” works fine with different channels, but that the 80mhz ac mode was set and saved.
As soon as I chose “ac 40mhz” or “ac 80mhz” the module is gone again.
I can revive it by switching wifi1 off, then using 2.4ghz mode and switching it back to 5ghz with mode either disabled, “n 20mhz” or “ac 20mhz” (didn’t try “n 40mhz”).

However it seemingly did work beforehand (at least that’s what was in the settings, didn’t check with another device previously). I get the same results with LuCy or Reforis, but only tried that after what I described above.

edit: found the bug, it doesn’t seem to be related to 5.2 though. see here

tac2 · May 29, 2021, 10:25am

Mox A + D
Smooth upgrade.
Nice new gui, thank you team!

radekpribyl · May 29, 2021, 3:26pm

I can see the same haas errors + quite a lot of:

May 29 15:12:38 omnia haas-proxy-start[9432]: 2021-05-29T17:12:38 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed'

Pepe · May 30, 2021, 2:58pm

We didn’t update Honeypot as a Service and unfortunately, this is happening and we know about it. It it not regression, which was caused by this update. These messages, which you can see are harmless.

More about it can be found here:

peci1 · May 30, 2021, 4:29pm

I’ve also been getting

Updater failed:

runtime: [string “requests”]:430: [string “utils”]:420: Getting URI (https://repo.turris.cz/hbt/omnia/lists/pkglists/netboot.lua) failed: Couldn’t resolve host ‘repo.turris.cz’

for a few days. Turris omnia on HBT. I don’t think I have connection outages…

Radomil_R · May 31, 2021, 8:33am

I have very similar problem with Turris Shield:

Updater failed:

runtime: [string “requests”]:430: [string “utils”]:420: Getting URI (https://repo.turris.cz/hbs/mox/lists/pkglists/datacollect.lua) failed: Couldn’t resolve host ‘repo.turris.cz’

Thanks for any advice…
R.

mionica · May 31, 2021, 3:27pm

5.2.0 broke my DNS setup - had kresd resolving some things using dnsmasq on :5353 (via custom script)
turned out running dnsmasq on :54 and forwarding there did work - I’ve no idea why this happened though
(I expect some “fix” now prevents using ports above 1024 - but still, I’d have liked to see this in some release notes, instead of me having to point every domain machine’s DNS to the DC while looking for a solution, instead of just using the mirror I was hosting on dnsmasq)

Edit 2: also, syslog-ng didn’t want to start at all after update - wasn’t happy about some of my settings. Also easily fixed, but I had a WTH moment when I realized /var/log/messages was gone…

Edit: Omnia user here, but I don’t expect there’s anything Omnia-specific in this

BobC · May 31, 2021, 3:43pm

Which 5.x release will force the 3.11.x upgrade?

I’m running 3.11.23 on my IGG Omnia in a generic configuration with ad-blocking enabled and a USB SSD configured as a NAS. Most traffic is on my wired LAN, with Omnia WiFi used only for home automation and other IoT devices (2.4 GHz) and my phone (5 GHz).

I used to run bleeding-edge builds, but stopped when 3.x went into maintenance mode, so my skills have gone a bit stale. I’d like to help with whatever pre-release is the last one before the forced upgrade. That is, I’d like to help test the forced upgrade process itself, not so much the underlying 5.x OS (which should be stable by then).

Is there a list I can join to be a forced-upgrade tester? All I’d ask for is a day’s notice so I can make a final backup.

Edit: I do have plans for 5.x after the upgrade, which will hopefully include adding a GSM/LTE modem and running a WireGuard VPN.