Turris OS 5.3 is released!

EDIT:

Ignore this. I only recently updated the router Omnia from Turris OS 3.x. It seems as part of its upgrade, SQM was left applying to the wrong interface and additionally is performing very badly. With SQM on the router disabled, things seem fine. I’ll ignore why SQM was performing so terribly until another day as its not really necessary on my current connection.


Original comment:

I just checked mine. I have two Turris Omnias. The first is the main router and was not upgraded yet; the second is a dual disk RAID10 NAS which I did upgrade. Tested using command line Ookla client:

Non-updated Omnia (TurrisOS 5.2.7):

Speedtest by Ookla

Latency:    22.12 ms   (6.72 ms jitter)
Download:   359.43 Mbps (data used: 389.9 MB)
Upload:    35.99 Mbps (data used: 18.5 MB)

Updated NAS Omnia (TurrisOS 5.3.0)

Plugged into router Omnia with cable via lan-lan sockets. Wi-Fi is disabled:

Speedtest by Ookla

Latency:     9.33 ms   (0.87 ms jitter)
Download:    25.55 Mbps (data used: 15.3 MB)
Upload:    36.89 Mbps (data used: 17.1 MB)

Interestingly, upload is full speed so it appears to be something on ingress causing an issue.

Yes, i have too this problem with speed on Turris 1.1 after update

I have a similar problem with my Turris Omnia 2019 after the update, WAN seems fine if I do the tests but no internet on the LAN nor WiFi, my WiFi does work and I can connect but it’s simply connected without internet. I expected to solve the problem by simply doing a rollback, but the problem persisted.Even a factory reset and reflashing the router with the medkit didn’t solve it.

after the 5.3.0 everything here seems the same? DHCP to cable.

Yes, as I described in my edited comment, I actually tracked it down to the upgrade to a second upstream Omnia from Turris OS 3.x to 5.x. Its SQM config’s port wasn’t renamed automatically (and additionally SQM seems to be performing poorly), but I only noticed it when testing speed after fixing the NAS issues with the downstream Omnia’s upgrade that this thread relates to.

So for me, the only actual issue with this upgrade was it removing mdadm and not cleanly rebooting following the upgrade.

The SQM issue is likely the same as outlined here: SQM and cake in TurrisOS 5.2.7 - far lower speed than the link - #8 by einar

2 Likes

Yes, thanks! Exactly that. I see you even had the interface name change issue.

I couldn’t get lighttpd to start after the update.

I had to update /etc/lighttpd/conf.d/ssl-enable.conf like this :

ssl.openssl.ssl-conf-cmd = (
“MinProtocol” => “TLSv1.2”,
“Options” => “-ServerPreference”,
“CipherString” => “ECDHE+AESGCM:ECDHE+AES256: CHACHA20:!SHA1:!SHA256:!SHA384”
)

$SERVER[“socket”] == “:443” {
ssl.engine = “enable”
ssl.pemfile = “/etc/lighttpd-self-signed.pem”
}

$SERVER[“socket”] == “[::]:443” {
ssl.engine = “enable”
ssl.pemfile = “/etc/lighttpd-self-signed.pem”
}

Moving ssl.pemfile to the SERVER directive. The package reinstall show the package is still giving the wrong sss.pemfile and lighttpd -t show errors.

Leaving it here, If it helps someone.

My blue omnia original, updated to 5.3, but I cannot access the web ui. I am able to ssh in, but not sure how to diagnose. I use acme.sh with letsencrypt to manage my device cert. Any pointers on where to look for the issue. I have tried multiple browsers and always get a “connection refused”

Hello there,

I updated to 5.3 and it worked well for a couple of days. However, from today, I am unable to log in to either ReForis or LuCI. However, SSH works perfectly fine. I tried restarting lighttpd and rebooting the router, but nothing changed.

Some comments suggested on the forum was to clear history and try another browser/computer. None of these worked for me. Syslog has a generic message indicating that authentication failed.

We have the same problem here with Omnia 2020. I can ping the WAN interface but nothing on LAN. Upgraded automatically from 5.2.7. Had to roll back.

I have the snapshot from 5.3 mounted but I am not sure how to extract anything useful out of it.

I think there should be a different issue. I am not able to reproduce it, and we would have noticed that.

lighttpd 1.4.56 and later inherit the TLS config from the global scope if the $SERVER["socket"] conditions contains only ssl.engine = "enable" and not any other ssl.* options

Copy&pasted from this issue: Restrict lighttpd to strong TLS cipher suites (#706) · Issues · Turris / Turris OS / Turris OS packages · GitLab

Would it be possible to reach our technical support department? They will be able to help you.

TOS (Indiegogo campain), HBS

There was “not detected USB key” (used as system storage) problem again, so it is still not solved (clean install to 5.2.7 was made about 2-3 weeks ago, so only one TOS update.

I have tried (2 times) to install Nextcloud via reForis, everything went OK, but when I have tried to run it, there was “503 Service Unavailaible” message.

Mаybe all this is due to my HW is dying slowly, maybe not…

I now also see this in the log:

2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/bin/foris-forwarder", line 11, in <module>
2021-11-10 10:12:06 err foris-forwarder[14097]:     load_entry_point('foris-forwarder==0.2.0', 'console_scripts', 'foris-    forwarder')()
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/foris_forwarder/__main__.py", line  111, in main
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/foris_forwarder/app.py", line 45,   in __call__
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/foris_forwarder/app.py", line 76,   in __init__
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/foris_forwarder/configuration.py",  line 157, in __init__
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/foris_forwarder/configuration.py",  line 170, in load_from_uci
2021-11-10 10:12:06 err foris-forwarder[14097]:   File "/usr/lib/python3.7/site-packages/euci/__init__.py", line 90, in get
2021-11-10 10:12:06 err foris-forwarder[14097]: uci.UciExceptionNotFound

With /etc/config/fosquitto being:


config global 'global'
        option debug '0'

config local 'local'
        option port '11883'

config remote 'remote'
        option enabled '0'

config subordinate '0000000D300058CB'
        option port '11884'
        option enabled '1'

Small update on my previous post: this might not have been related to the update, since I couldn’t get a mox connecting either. What the problem was probably will be a mystery forever though since I didn’t had time to figure out what the problem was and simply used a spare router for a week. When I hooked up the mox it immediately worked, same for the omnia. :neutral_face:

1 Like

While checking the last log, I registered an irregularly recurring error this day. This error is not noticeable (obvious) for litter dumps in the log.
foris-controller[6051]: WARNING:foris_controller_backends.collectd:Socket error occured '[Errno 2] No such file or directory'

The mentioned error

Nov 18 16:49:33 Turris_Omnia sentinel-dynfw-client [2998]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it's not added
Nov 18 16:49:33 Turris_Omnia sentinel-dynfw-client [2998]: 2021-11-18 17: 49: 33,297 - WARNING - Error running ipset command: return code 1.

I will restart and verify the existence of the error

EDIT: the error is repeated - Diagnostics Report - created and saved.

Nov 18 20:16:14 Turris_Omnia sentinel-dynfw-client[3007]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it's not added
Nov 18 20:16:14 Turris_Omnia sentinel-dynfw-client[3007]: 2021-11-18 21:16:14,417 - WARNING - Error running ipset command: return code 1.

EDIT
ipset list is working

x
x
x
182.112.14.239
87.13.17.136
67.241.249.87
115.63.22.181
14.231.104.27
14.104.170.201
103.82.79.14
123.4.212.136
123.169.120.71
185.243.68.9
122.5.204.23
112.85.172.66
156.67.250.41
root@Turris_Omnia:~#

==============================
EDIT: Uhhh … only warning ?

Wow what a mess!
This afternoon, Updated to 5.2.7 OK
Updated to 5.3.0 Fubar! No LXC and as a result a lot of my systems were off line (house automation and pihole etc).
15 mins before a conference call for work so reverted to a snapshot with a view to resolve at my leisure.
23:15 and I am having to fix it all again, seems that even though I have “update approval needed” turned on, if I have reverted to a previous snap shot then this seemed to be ignored and the system reinstalled the updates again! Not what I needed before going to bed!

Tried to revert to a snapshot but that failed so ended up searching through this thread to find I needed to remove the details from /etc/config/storage

I’m back up and running now but very disappointing and annoyed!!!

This topic was automatically closed after 19 days. New replies are no longer allowed.

Thanks for sharing your feedback anyway with us. It pushes us forward. :+1:

The storage issue was described here a lot, so anything surprising, I would say. Unfortunately, it was not caught during our public testing - Turris OS 5.3 is in HBT (Testing) branch! It was there were almost three weeks, and no one reported it to us. Currently, we don’t have tests for Storage plugin, and it is the culprit on our side, too.

We informed you here on the forum that we are preparing Turris OS 5.3.1, which was recently released, and we hope that it fixes the issue for you. You can join us to make our products better. Our positions are still open.

1 Like