Turris OS 5.0.3 is out!

Dear Turris users,

We just released a new Turris OS 5.0.3, which is in HBS (Stable) :snail: branch. It is released for all Turris routers. If you are using automatic updates, you will be updated to this automatically. If you are using Approvals or Delayed updates, check Foris to apply the update.

This is a security update with bug fixes.

Developer changelog:
OpenWrt feed:

  • kernel update to version 4.4.187 from 4.4.180 (fixes CVE-2020-10757)
  • wireguard update to version 1.0.20200611

Packages feed:

  • nextdns: update to version 1.7.0
  • https-dns-proxy: remove eDNS support
  • add conffiles to irqbalance
  • acme: update and handle log messages and ecc cert corrrectly
  • miniupnd: update to version 2.1.20200510
  • syslog: detect disabled IPv6 on loopback and fallback to IPv4

Our changes:

  • experimental migration: improvements for Turris 1.x routers
  • nextcloud: updated to version 17.0.5
  • mox-otp: update to version 0.3 (supports new kernel versions as well)
  • knot-resolver: update to version 5.1.2

We appreciate any feedback for this release.

4 Likes

List of known bugs:

Since Turris OS 3.x release:
This time, there was no any ddns-package update, so you don’t need to worry about, but if you came from earlier versions of Turris OS, be careful!

Since Turris OS 4.x release:

  • In some cases, Turris MOX is not correctly rebooted.
  • MOX SDIO Guest networking might not be supported in the stable branch. There’s a possibility to check HBK/HBL branches for improvements.
  • You can not have installed ttyd and mosquitto at the same time. This is an upstream issue and it was reported to them. See https://github.com/openwrt/packages/issues/11632

Since Turris OS 5.0 release:

  • Some Knot DNS packages can not be installed. This is going to be fixed with Turris OS 5.1/5.2.
  • Package v4l-utils was not compiled.
2 Likes

Hello,

Mox Classic still does not reboot , must be unplugged from power supply and plugged again.
Is there any chance to fix this ?

Hello,

I’d kindly ask you to take a look at the list of known bugs or use the search button. We are aware of this issue, and kernel developers are working on it together with the SoC manufacturer. If there’s going to be a workaround/fix, we will let you know about that, and also, in that case, we will update the current list of known bugs.

If I am not mistaken, I think that this issue from you complained about it in every discussion where was Turris somehow mention. However, I was not able to found any support ticket from you regarding this issue. If you are not satisfied, we can not solve it here either in other places. In that case, the support department is available for you. Take a look at Getting help article.

I have issue with OpenVPN. It seems it is in the endless loop with average load about 2.0-2.5:

log exerpt
...
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: OpenVPN 2.4.7 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Diffie-Hellman initialized with 2048 bit key
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: TUN/TAP device tun_turris opened
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is enabled
Jul 10 07:56:34 omnia netifd: Network device 'tun_turris' link is up
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' has link connectivity 
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is setting up now
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: TUN/TAP TX queue length set to 100
Jul 10 07:56:34 omnia netifd: Interface 'vpn_turris' is now up
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris 192.168.123.1 pointopoint 192.168.123.2 mtu 1500
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris add 2001:db8:d01::1/64
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: /sbin/route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.123.2
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: UDPv4 link local (bound): [AF_INET][undef]:1194
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: UDPv4 link remote: [AF_UNSPEC]
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: MULTI: multi_init called, r=256 v=256
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL IPv6: (IPv4) size=62, size_ipv6=65536, netbits=64, base_ipv6=2001:db8:d01::1000
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL: base=192.168.123.4 size=62, ipv6=1
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: IFCONFIG POOL LIST
Jul 10 07:56:34 omnia openvpn(server_turris)[11022]: Initialization Sequence Completed
Jul 10 07:56:36 omnia firewall: Reloading firewall due to ifup of vpn_turris (tun_turris)
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: event_wait : Interrupted system call (code=4)
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/route del -net 192.168.123.0 netmask 255.255.255.0
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: Closing TUN/TAP interface
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris 0.0.0.0
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: /sbin/ifconfig tun_turris del 2001:db8:d01::1/64
Jul 10 07:56:37 omnia netifd: Network device 'tun_turris' link is down
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' has link connectivity loss
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' is now down
Jul 10 07:56:37 omnia openvpn(server_turris)[11022]: SIGTERM[hard,] received, process exiting
Jul 10 07:56:37 omnia netifd: Interface 'vpn_turris' is disabled
...
1 Like

I’m experiencing the same issue, not only with openvpn server but as well when using openvpn as client.

I had the same issue after upgrading to 5.0.2 from 3.11.17.
After a reboot it did not occur again.

I don’t know. After reboot it shows again. But after some time (dunno how much, I checked again after 4 hours) it was calm.

Update 5.0.2->5.0.3 on Omnia with system on SSD triggered an unwanted restart in the middle of the update.

Last logged updater action before the restart:

00:55:08 warning updater[4163]: backend.lua:786 (pkg_merge_files): Config file /etc/ppp/options.pptpd modified by the user. Backing up the new one into /etc/ppp/options.pptpd-opkg

Restart (last logged message at all) was at 00:56:02, syslog started again at 00:56:52.

Start of updater log after the restart:

00:56:57 info /updater-supervisor[]: Running pkgupdate
00:56:57 info updater[8556]: src/pkgupdate/main.c:144 (main): Detected existing journal. Trying to recover it.
00:56:57 notice procd[]: /etc/rc.d/S85updater-journal-recover: Supervisor:Running pkgupdate
00:57:00 info updater[8556]: transaction.lua:235 (fun): Removing packages and leftover files
00:57:00 info updater[8556]: transaction.lua:240 (fun): Running post-install and post-rm scripts
00:57:00 info updater[8556]: src/lib/logging.c:204 (log_subproc_open): Running postinst of ca-certificate

hi all, after the update to 5.0.3 (from 5.0.2), I have noticed sudden changes in the timestamps in the log of my TO, please see an excerpt below, with timestamp changing +/- 2h back and forth. Would anyone please have a hint what could be the reason and where to fix it?
Correct time is 09:xx:xx, set in LuCi in system properties.

...
Jul 12 09:13:43 turris kernel: [   29.566209] br-lan: port 7(wlan1) entered forwarding state
Jul 12 07:13:47 turris kresd[7098]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Jul 12 09:13:43 turris dnsmasq[6842]: started, version 2.80 DNS disabled
Jul 12 09:13:48 turris dnsmasq[6842]: overflow: 5 log entries lost
Jul 12 09:13:48 turris dnsmasq-dhcp[6842]: DHCPACK(br-lan) [redacted]
Jul 12 07:13:48 turris /dhcp_host_domain_ng.py: DHCP add new hostname [redacted]
Jul 12 07:13:48 turris /dhcp_host_domain_ng.py: Refresh kresd leases
Jul 12 07:13:50 turris firewall: Reloading firewall due to ifup of wg1 (wg1)
Jul 12 07:13:50 turris kresd[7337]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Jul 12 07:13:53 turris firewall: Reloading firewall due to ifup of wan (eth2)
Jul 12 07:13:53 turris kresd[7566]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Jul 12 07:13:54 turris hostapd: wlan0: ACS-COMPLETED freq=5180 channel=36
Jul 12 07:13:54 turris hostapd: wlan0: interface state ACS->HT_SCAN
Jul 12 07:13:54 turris hostapd: Using interface wlan0 with hwaddr 04:f0:21:31:d9:87 and ssid [redacted]
Jul 12 09:13:54 turris kernel: [   39.777205] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jul 12 09:13:54 turris kernel: [   39.783689] br-lan: port 6(wlan0) entered blocking state
Jul 12 09:13:54 turris kernel: [   39.789018] br-lan: port 6(wlan0) entered forwarding state
Jul 12 07:13:54 turris hostapd: wlan0: interface state HT_SCAN->ENABLED
Jul 12 07:13:54 turris hostapd: wlan0: AP-ENABLED 
Jul 12 07:13:55 turris netifd: Network device 'wlan0' link is up
Jul 12 07:13:56 turris firewall: Reloading firewall due to ifup of wan6 (eth2)
Jul 12 07:13:56 turris kresd[7826]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Jul 12 07:14:00 turris hostapd: wlan0: STA 84:3a:4b:64:26:72 IEEE 802.11: authenticated
Jul 12 07:14:00 turris hostapd: wlan0: STA 84:3a:4b:64:26:72 IEEE 802.11: associated (aid 1)
Jul 12 07:14:00 turris hostapd: wlan0: AP-STA-CONNECTED 84:3a:4b:64:26:72
Jul 12 07:14:00 turris hostapd: wlan0: STA 84:3a:4b:64:26:72 RADIUS: starting accounting session 99D4C8FABE386645
Jul 12 07:14:00 turris hostapd: wlan0: STA 84:3a:4b:64:26:72 WPA: pairwise key handshake completed (RSN)
Jul 12 09:14:01 turris dnsmasq-dhcp[6842]: DHCPREQUEST(br-lan) [redacted] 
Jul 12 09:14:01 turris dnsmasq-dhcp[6842]: DHCPACK(br-lan) [redacted]
Jul 12 07:14:01 turris /dhcp_host_domain_ng.py: DHCP add new hostname [redacted]
Jul 12 07:14:01 turris /dhcp_host_domain_ng.py: Refresh kresd leases
Jul 12 07:14:10 turris hostapd: wlan1: STA 20:3d:bd:57:a8:f0 IEEE 802.11: authenticated
Jul 12 07:14:10 turris hostapd: wlan1: STA 20:3d:bd:57:a8:f0 IEEE 802.11: associated (aid 1)
Jul 12 07:14:10 turris hostapd: wlan1: AP-STA-CONNECTED 20:3d:bd:57:a8:f0
Jul 12 07:14:10 turris hostapd: wlan1: STA 20:3d:bd:57:a8:f0 RADIUS: starting accounting session 5C31D3DFA2FC74C9
Jul 12 07:14:10 turris hostapd: wlan1: STA 20:3d:bd:57:a8:f0 WPA: pairwise key handshake completed (RSN)
Jul 12 09:14:10 turris dnsmasq-dhcp[6842]: DHCPREQUEST(br-lan) [redacted] 
Jul 12 09:14:10 turris dnsmasq-dhcp[6842]: DHCPACK(br-lan) [redacted]
Jul 12 07:14:10 turris /dhcp_host_domain_ng.py: DHCP add new hostname [redacted]
Jul 12 07:14:10 turris /dhcp_host_domain_ng.py: Refresh kresd leases
...

such been mentioned in this thread

1 Like

Apparently turris omnia now got attacked.
Not sure if attacker got stuck in vodka modem or
got stuck in omnia.
last logged IP was 10.135.132.246 and wlan of turris was down since then.
It was version 5.0.3 inside since Friday.
I switched devices off and look again next evening.

Other IPs of attack after this were (WLAN of turris for handy) :

$ netstat tulpen

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 10.143.1.126:47311 149.154.167.51:https ESTABLISHED

tcp 0 0 10.143.1.126:47309 149.154.167.51:https ESTABLISHED

tcp6 0 0 10.121.127.2:49005 fra16s18-in-f133.:https ESTABLISHED

tcp6 0 0 10.143.1.126:41143 93.184.221.187:https ESTABLISHED

tcp6 0 0 10.143.1.126:46497 108.177.122.188:5228 ESTABLISHED

tcp6 1 0 10.143.1.126:49902 74.125.136.100:https CLOSE_WAIT

udp6 0 0 10.121.127.2:49542 fra1.blocka.net:51820 ESTABLISHED

Active UNIX domain sockets (w/o servers)

After bigger pause for devices - all seems to work again.
(checking now WLAN … ) … YES ! - WLAN is working too again.
Seems - nothing wrong with 5.0.3
… your devices need more often pauses … !!! So switch off more often !!!

1 Like

Just to be sure to understand correctly, the “list of known bugs” means “list of known bugs that are not yet fixed”, not “list of known bugs that are fixed in this release”, correct?

Correct. List of known notable bugs present in 5.0.3.

Good day, I did a clean flash to 5.0.3 since the router was not in use for a couple of months.

I followed this documentation:
https://docs.turris.cz/basics/first-setup/simple_setup/

Problems I encountered with the fresh install:

  1. DHCP (IPv4) was not working, I had to set a static IPv4 address to be able to open Foris (IPv6 was working but I didn’t find the IPv6 address of Foris). After clicking around a little bit in the Interfaces in LuCI both LAN and WLAN now has DHCP for IPv4 and IPv6, but I didn’t apply any changes it just worked after a couple of restarts.
    Also http://turris.local was not accessible but is now.

  2. Switching WAN to SFP was not trivial, because the documentation does not cover this.
    I found the command to switch the softlink in /boot on some random google search.

  3. The web interface is exposed to WAN by default! I only noticed this because I had DDNS before and my ISP assigned me the same public IP as before, so my Caldav clients got an untrusted certificate (the self-signed default one) when trying to connect.
    IMO the web interface ports 80/443 should not be open by default!

Cheers!