Turris OS 6.1.0 is now released for Turris Omnia and Turris MOX

I only use HTTP (internal network). I don’t have antivirus.

Please note the update. New errors have been logged.

Omnia 2016 ( simple basic cfg ) and Mox Classic ( simple basic cfg , VLAN PPPOE) Zero problems.

Everything seems to be working but in reForis I am getting this error:

3 Likes

Try http://192.168.1.1 instead of https://

I found trace and managed to fix the issue
trace

I have static dns lease with lease time infinite for one of my client which also have ipv6 and its DUID was not included in static lease, therefor for some unknow reason after update it get value -1 for expires instead of 0.

Its probably not update releated but it just came up to me after update. Sorry for noise.

I have the same issue in reForis - for LAN - unknown API error. But in my case traceback in /var/log/lighttpd/error.log contains messages related to br-lan. So I would say something related to VLANs, as my LAN is configured as VLAN101, hence on br-lan.101. Maybe reForis does not understand DSA config? I am not sure if it was introduced by 6.1.0 or it was there also when I was running 6.0.x. Below traceback messages:

2022-12-22 16:19:06: (../src/server.c.1588) server started (lighttpd/1.4.67)
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:[2022-12-22 16:22:35,146] ERROR in backend: Exception in backend occurred. (Controller error(s) has occured:
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:Traceback (most recent call last):
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/message_router.py", line 117, in process_message
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/module_base.py", line 61, in perform_action
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_modules/lan/__init__.py", line 36, in action_get_settings
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/utils.py", line 113, in inner
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_modules/lan/handlers/openwrt.py", line 41, in get_settings
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_backends/lan/__init__.py", line 262, in get_settings
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_backends/lan/__init__.py", line 201, in get_ipv6_client_list
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:KeyError: 'br-lan'
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:Internal error 'br-lan'('<class 'KeyError'>')
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:
2022-12-22 16:22:34: (../src/mod_fastcgi.c.450) FastCGI-stderr:)
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:[2022-12-22 16:22:42,157] ERROR in backend: Exception in backend occurred. (Controller error(s) has occured:
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:Traceback (most recent call last):
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/message_router.py", line 117, in process_message
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/module_base.py", line 61, in perform_action
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_modules/lan/__init__.py", line 36, in action_get_settings
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller/utils.py", line 113, in inner
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_modules/lan/handlers/openwrt.py", line 41, in get_settings
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_backends/lan/__init__.py", line 262, in get_settings
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:  File "/usr/lib/python3.9/site-packages/foris_controller_backends/lan/__init__.py", line 201, in get_ipv6_client_list
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:KeyError: 'br-lan'
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:Internal error 'br-lan'('<class 'KeyError'>')
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:
2022-12-22 16:22:41: (../src/mod_fastcgi.c.450) FastCGI-stderr:)

Any idea how to fix it?

Turris 1.1 running 6.1.0.

1 Like

Guys, we have taken your WAN issue on Turris 1.x very seriously. We are still investigating why and when it could happen to you since, in our environment, it works. In any case, we wanted to ensure you and us that the Christmas holiday would be peaceful and we need some time to know what is going on. We pushed revert for Turris 1.x routers, that means that Turris OS 6.1.0 is now released only for Turris Omnia and Turris MOX. We are going to keep it like this because for these routers, there are no breaking changes except for Nextcloud, which is now using PHP8.

If you are using kernel 5.15 on Turris 1.x, you will be downgraded to Turris OS 6.0.4.

4 Likes

For me update from 6.0.4 to 6.1.0 worked like a charm on Turris 1.1. But few months ago I did clean installation because I was not able to update to Turris 6.

2 Likes

I am afraid that we did not count on the such configuration in reForis. I’ve checked the source code, and it is indeed looking for br-lan and if it is missing, it will fail. We will consider if it makes sense to support this kind of non-standard configuration in reForis. Thanks for reporting!

1 Like

Thank you! :slight_smile: I have been checking the support system, etc. for whole day to ensure that it is working as it should, but still if WAN is not working in some environment, it is crucial to have working Internet connection, thus rather be safe and sure than regret.

2 Likes

My Turris 1.1 worked on TOS 6.1.0 without a problem. So it’s just a pity about two reboots today.

I had the same problems with TOS 6.1.0 as my colleagues. Reboot didn’t help. Only disconnecting and reconnecting the power supply helped. Now Turris works. Clean install of TOS6.0.4 from medkit, then up. T1.1, now TOS 6.1.0

Turris Omnia 1GB (2016) Indiegogo
minor configuration:
adblock, banIP, collectd, sqm, sentinel, snowflake

Worked flawlessly!

Hey, @Pepe . I’ve had a few pieces of Turris 1.1 at home. I’ve been putting off updating to TOS6 indefinitely, but now I’ve got a bit of time, so I’ve gone ahead. I’ve come across some interesting behavior with some routers/modems since TOS6. It’s possible that with the next kernel update for TOS6.1 it got even worse.
I have a dual WAN (wan+lan1). Two different providers, two different technologies. The behavior is the same even after swapping connections. This rules out a specific configuration for the secondary WAN.

  1. LTE, Nordic Telecom, static public IP, bridge-mode modem (IDK)
  2. DSL, O2, dynamic public IP, NAT modem (ZTE ZXHN H168N)

TOS5 (5.4.4): Both connections “reliable” and functional.
TOS6 (6.0.4):

  • LTE reliable and functional.
  • DSL
    • Connection established.
    • IP from modem assigned.
    • Access to modem and other devices on the network functional.
    • Access to public network not functional. No PING or other query will pass.

Arbitrarily repeatable by rollback/update.
I’ll do some experiments with the one router I have lying around right now to cover single WAN and a clean install of TOS6 from medkit.

6.0.4->6.1.0 update ok (no new problems introduced), no unintended cable/wifi or internet downtime. Restart needed.


First, I could not find the new WAN VLANid settings in Reforis. But after deleting caches in browser (Ctrl-F5), it is right there!

WAN page:

obrazek

Interfaces page:

obrazek

However, the non-VLAN WAN port is also still displayed, which might be confusing for someone:

And the problem with wifi interfaces reported as unassigned still remains from 6.0.0.


There is also an issue with morce I observe all the time on 6.x: I did not yet have time to configure it properly, so I manually disabled morce and snort (/etc/init.d/{morce,snort} disable) so that they do not spam my logs. However, after each update, I find both snort and morce enabled and running.


Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, morce.

MOX A+D 6.0.4 → 6.1.0 smooth sail
Reboot worked

Have not tested the usb yet. I only use it for log retention Which is disabled at the moment.

Only minor thing I noticed is the ”region and time” page in reforis presents ”an unknown API error occured.”
Have not tried to debug it.

Thank you team!

I just did my Omnia today from 5.4.4 to 6.1.0.

No issues whatsoever, christmas lights also work (minus the front panel brightness setting, but I don’t mind that).

I have lxc, samba, collectd/rrd, hd-idle on a spinning hdd and transmission.

I was prepared for a fight :smiley:, but it all worked.

Turris 1.x
today there was an automatic reset after the update.
Internet connection not working.

net eth2: could not attach to PHY

The connection is via PPPoE. ISP cable goes to wan (no modem)

I’m in HBT, so the settings only took effect now, and the updater still offers me 5.15.84 as the kernel version

Do you need another log?

1 Like

Yep, the kernel 5.15 is only in HBT for testing, so if you are using HBS/HBK, there is kernel 5.10 for now. In any case, diagnostics would be nice to have.

Diagnostics sent [turris-L1 #1506629], if I used rollback on postupdate, turris pretended normally.

It doesn’t work after auto reset.

//update
after a certain time the problem occurs again

1 Like