Turris OS 4.0 beta8 is released!

Community office
,
1

Dear Turris users,

We released a new beta8 version of Turris OS 4.0 for Turris Omnia and Turris MOX. This release contains mostly several security fixes in kernel, subversion, clamav, mariadb also there are updated packages like Nextcloud, Unbound, Foris, sentinel-certgen, …

Release notes for this release are:

  • nextcloud: updated to version 16.0.3
  • mariadb: updated to version 10.4.7
  • unbound: updated to version 1.9.2
  • foris: updated to version 100.3
    • PPPoE credentials in WAN tab are now mandatory
    • fixed connection test (turris/foris#171)
  • sentinel-certgen: updated to version 6.1.3 (fixes turris/sentinel/certgen#12)
  • nodogsplash: updated to version 4.0.1
  • libaio: updated to version 0.3.112
  • libdouble-conversion: updated to version 3.1.4
  • subversion: fix for CVE-2018-11782, CVE-2019-0203, CVE-2018-11803
  • kernel: fix for CVE-2019-3846, CVE-2019-3900, CVE-2019-13648, CVE-2019-10207

When you are using previous Turris OS 4.0 beta7 release and if you are not using approvals, you should be updated to this version automatically. If you do, there will be waiting for you a notification in Updater tab to approve the update.

If you would like to try this release instead of Turris OS 3.x release on Turris Omnia and start from scratch, you need to download medkit to USB flash drive, which will be formatted on EXT2/3/4. Don’t extract it and plug it to the Turris Omnia router and by using re-flash method (4 LED), it will erase all the data from the current operating system including and write there a new operating system Turris OS 4.0.

We are looking forward to receiving your feedback for this release.

1 Like
2

Known bugs:

Turris Omnia specific

  • There are two 2 ethernet controllers on CPU connected to switch chip. Only one of two ethernet ports between CPU and switch is in use as kernel DSA subsystem does not support multiCPU, yet. WAN / SFP and all LAN ports are working.

Turris 1.x specific

  • Currently not working because of kernel issues. Please do not test this release on Turris 1.x.
3

Manual update from beta7:

## Error from 2019/08/08 16:50:52

Updater selhal: 

inconsistent: Requested package mox-support that is not available.
2 Likes
4

Thanks for reporting. We are looking into it.

1 Like
5

After some investigations, we decided to postpone the update for Turris MOX to fix this issue properly. Thank you for your understanding.

1 Like
6

Since update to TOS 4.0 beta8 on my Turris Omnia I get errors for my “VPN policy based routing”:

Blockquote
Aug 9 03:28:33 turris vpn-policy-routing [5716]: Routing ‘Client’ via VPN_client [✓]
Aug 9 03:28:34 turris vpn-policy-routing [5716]: Routing ‘IP_Range’ via wan [✓]
Aug 9 03:28:34 turris vpn-policy-routing [5716]: service started on wan/185.XXX.XX.1 with errors [✗]
Aug 9 03:28:34 turris vpn-policy-routing [5716]: ERROR: Failed to set up ‘VPN_client/10.XX.XX.62 peer 10.XX.XX.61’
Aug 9 03:28:34 turris vpn-policy-routing [5716]: service monitoring interfaces: wan VPN_client [✓]

Up to beta 7 it was working without issues. Anybody also using VPN PBR with Turris Omnia and bete8?

7

Do you have really beta 8 on your MOX?

There is a small discussion about the main topic: “What system actually installed on my MOX?”

8

Try restarting VPBR, either via LuCI or cli. If that does not sort it then perhaps the VPN interface is not up.

Suppose the router been rebooted after the upgrade to beta 8?

9

I tried that already. All didn’t help. The tun0 interface is up and I also get the VPN IP for the client routed over the VPN, but I don’t know if the traffic is correctly only going over the VPN due to the error of VPN PBR

10

Since VPBR being a package fetched from outside the TOS/OpenWrt feed it might be better to move this to VPN policy based routing possible?

Meantime, you could check from the cli /etc/init.d/vpn-policy-routing status

11

thanks for the update, can confirm that the dns-testing on foris is working again…still got 2 errors in the logs since i switched to beta even on a fresh reset:
1.
keep 99-dhcp_host_domain_ng.py: DHCP unknown update operation

followed by a message like this for every fixed dhcp lease i set in luci:

kresd[18038]: hints.del('HOSTNAME.DOMAIN')
kresd[18038]: [result] => true
kresd[18038]:

In Systemlog timestamps from services seems 2 hours shifted i guess i need to set somewhere the right timezone?

keep up the hard work and greetings to my root-country CZ :wink:

1 Like
12
  1. I see these also on a regular basis but slightly different

Aug 9 17:14:14 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Aug 9 17:14:14 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Aug 9 17:14:14 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Aug 9 17:14:14 TurrisJK kresd[6546]: > hints.del(‘Jack.lan’)
Aug 9 17:14:14 TurrisJK kresd[6546]: [result] => false
Aug 9 17:14:14 TurrisJK kresd[6546]:

  1. My timezone is set correctly but the time stamps in the log-file are also 2 hours off (2h to earlier).
13

And now something completely… B8 seems to be finally there.

1 Like
14

If that pertains to syslog there is

If it pertains to Foris there is

15

After upgrade from beta7 to beta8 I’m unable to access Foris even after several reboots on Omnia

image
image803×544 28.6 KB

2 Likes
16

Since midnight this release is also available for Turris MOX.

1 Like
17

Not yet able to reproduce it, but I am looking into it.

2 Likes
18

Please, don’t confuse others with multiple issues. The second one is completely irrelevant. It is about to switch notification time in local timezone instead of UTC. Notifications all the time shows the correct time instead of some processes in the log file.

19

I also have a bug on Foris, MOX, beta 8.

20

same ( mox classic ) here, can’t acces foris. Luci works fine.