Turris OS 3.8.2 out with DNS and security fixes

Vaclav · October 3, 2017, 11:07pm

The whole Turris team is responsible and everyone can help by switching to RC branch (and migrate to Btrfs first on Turris 1.x before ) We are very sorry this time.

Vaclav · October 4, 2017, 8:51am

A post was merged into an existing topic: Problémy po aktualizaci Turris 1.x na 3.8.2 // volná diskuze

vcunat · October 4, 2017, 10:50am

Since 3.8 on Omnia, DNS forwarding mode also validates by default. In knot-resolver >= 1.4.0 we added a workaround fixing the situation for some ISPs, but that’s not in Omnia stable yet.

Vaclav · October 4, 2017, 1:34pm

You can turn off the forwarding or DNSSEC feature in Foris DNS settings. And what is your Turris model?

cefeus · October 4, 2017, 2:02pm

I have a Turris Omnia.

ssdnvv · October 4, 2017, 8:06pm

After restart I have a new problem - the internet connection drops out every now and then! As my girl friend doesn’t like that (especially because of Netflix) I have to revert back to 3.8.1.
Before the restart I had no network drop outs…

Teni · October 4, 2017, 8:15pm

I’m experiencing an issue too.
After the update and restart the DHCP server is not working - I do not get the IP address.
I am not able to connect to the Turris’s web admin interface. Not even whenI connect directly to the Turris and manuallly set my IP adress to 192.168.1.X

What am I supposed to do now?
Should I just plug it to the internet and wait? Is the device able to recover itself when you release a fix?
Or should I reset to factory defaults?
Or something else?
The only diagnostic info I have is the e-mail sent by the device informing me about the upcoming restart:
https://drive.google.com/file/d/0ByYX47xCt_uKS2h6ZFJVcG9uMjg/view?usp=sharing
Thanks

ssdnvv · October 4, 2017, 8:20pm

By the way - how do I deny automatic updates? In foris there seems to be no more option for that?! Because “update approval needed” does not work…

Fenevadkan · October 6, 2017, 11:22am

I have tried OpenVPN easy setup via Foris in TurrisOS 3.8.1 and also in 3.8.2 and connection does not work. I only used the config in the Foris GUI and tried to connect via and android phone, with the official openvpn application. I donwloaded the config from Foris renamed the extension to.ovpn and loaded it. I can see the connection requests coming into the router in the /var/log/messages, and times out:

2017-10-06T11:20:24+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:35050 TLS: Initial packet from [AF_INET]192.168.1.194:35050, sid=27b23860 53d503d5
2017-10-06T11:20:29+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:33444 TLS: Initial packet from [AF_INET]192.168.1.194:33444, sid=05980e5a 5f69fc7f
2017-10-06T11:20:39+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:50055 TLS: Initial packet from [AF_INET]192.168.1.194:50055, sid=a8bc2cfa ac3d61a7
2017-10-06T11:20:49+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:33768 TLS: Initial packet from [AF_INET]192.168.1.194:33768, sid=7f81e23a 652df598
2017-10-06T11:20:59+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:53266 TLS: Initial packet from [AF_INET]192.168.1.194:53266, sid=d5ee60b7 97fd394c
2017-10-06T11:21:01+02:00 info /usr/sbin/cron[6496]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
2017-10-06T11:21:09+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:52731 TLS: Initial packet from [AF_INET]192.168.1.194:52731, sid=d63de698 dc87ff14
2017-10-06T11:21:24+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:35050 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2017-10-06T11:21:24+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:35050 TLS Error: TLS handshake failed
2017-10-06T11:21:24+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:35050 SIGUSR1[soft,tls-error] received, client-instance restarting
2017-10-06T11:21:30+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:33444 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2017-10-06T11:21:30+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:33444 TLS Error: TLS handshake failed
2017-10-06T11:21:30+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:33444 SIGUSR1[soft,tls-error] received, client-instance restarting
2017-10-06T11:21:39+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:50055 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2017-10-06T11:21:39+02:00 err openvpn(server_turris)[2374]: 192.168.1.194:50055 TLS Error: TLS handshake failed
2017-10-06T11:21:39+02:00 notice openvpn(server_turris)[2374]: 192.168.1.194:50055 SIGUSR1[soft,tls-error] received, client-instance restarting

einar · October 6, 2017, 11:42am

TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Notice that this can also occur if the clocks of the server and the client are skewed.

waffle · October 6, 2017, 11:43am

This update, once again, broke DNS for me. But I know the culprit now.

I have the startup service “resolver” disabled because I use Pi-Hole as my DNS server. This update, like the one previous, automatically reenabled “resolver.” Everything else (WAN interface) points to my Pi-Hole as DNS, yet the Omnia (I’m guessing) is looking to the stock resolver service. Connecting to DHCP takes minutes, but once I’m finally connected I can navigate to the Omnia (no internet, though, no DNS), disable “resolver,” reboot, and all is well again.

I also have the “kresd” service disabled, and this did not get auto reenabled with the update.

So, this has me believing that these updates are forcing the reeneabling of “resolver” even if it has purposefully been marked “disabled.” Can that please be changed? If I disable a service, I have a good reason to do so. I understand the importance of “resolver” in a stock setup, but updates should not make changes like this on unique configurations. It makes having auto update a liability, instead of a benefit.

Fenevadkan · October 6, 2017, 11:46am

thanks for the hint. I checket and it seems all devies show the correct CEST time.
So the issue here is probably not the clock difference

Jirka · October 6, 2017, 9:05pm

Turris Omnia. since version 3.8 or 3.8.1 I have repeated

2017-10-06 21:02:04 info dhcp_host_domain_ng.py[]: DHCPv4 new lease
2017-10-06 21:02:04 warning dhcp_host_domain_ng.py[]: Add_lease, hostname check failed
2017-10-06 21:02:04 warning dhcp_host_domain_ng.py[2100]: Last message 'Add_lease, hostname ' repeated 2 times, suppressed by syslog-ng on Doma

2017-10-06 22:15:44 warning dhcp_host_domain_ng.py[]: Add_lease, hostname check failed
2017-10-06 22:15:44 info dhcp_host_domain_ng.py[]: DHCP add new hostname [loznice,10.0.5.111]
2017-10-06 22:15:44 info dhcp_host_domain_ng.py[]: Refresh kresd leases
2017-10-06 22:37:49 info dhcp_host_domain_ng.py[]: DHCPv4 new lease
2017-10-06 22:37:49 warning dhcp_host_domain_ng.py[]: Del_lease, hosname check failed

etc. in log… Irritating. Before everything works without this strange script. I am using static leases for LAN devices.

As workaround I am using
# option dhcpscript '/etc/resolver/dhcp_host_domain_ng.py' - New since 3.8, troublemaker

in
/etc/config/dhcp

freshdax · October 8, 2017, 1:38pm

The same with me, no problems with the installation. It seems quite stable now, if you do not make profound changes to the settings.

X-dark · October 10, 2017, 12:35pm

This script is supposed to inject entries from dhcp entries. But I get errors as well: Dhcp_host_domain_ng.py removes local-data entries