Turris OS 6.0 is released

[Pepe]

@milkandhoney

inconsistent: Requested package wireguard that is not available. 

This is described in the 2nd post, we will fix it in upcoming update.

@milkandhoney

inconsistent: Requested package usbreset that is not available.

https://github.com/openwrt/openwrt/commit/6cda95431984312d15032f6466b3b7238936185b

It is part of usbutils package.

usbutils: add usbreset

[Broody]

@anarcat

@samm_git

Anyway, I would like to thank the entire Turris team for their hard work. Having 10+ years of support for the home router is just amazing.

I want to emphasize this here as well. I understand some people might be upset by some of the inconveniences of this update, but this is a major upgrade, and I’m not actually surprised it’s a little more disruprive than it should be. It’s a little troubling – I would have expected a beta to catch stuff like this, for example – but nothing the call home about…

Totally agree. It’s not always smooth sailing, but overall I very much appreciate the longevity, utility and customizability of Turris routers.

[anarcat]

@Broody

It’s not always smooth sailing

See, even there I think I’ve had a pretty good ride. This router has been in production for almost six years now, and it’s the first time I have something this bad to report. (I wrote this review back in 2016! The Turris Omnia router: help for the IoT mess? - anarcat) So I think that qualifies as pretty smooth sailing in my book.

What other COTS router do you know that’s been supported, with automated reboots that always work, for six years?

[Radovan_Haban]

“I have something this bad to report”
I don’t agree. I have experience such serious problems twice in my six years history.
I’ve Synology devices at home 8 years and I never experienced something like this…

The worst thing is that Turris is “able” to open it’s internal configuration UI to Internet “automatically” in case of update problems!

[moeller0]

@anarcat

A reboot is not great, but it’s not that bad folks. Unless you’re running this stuff in production, in an actual datacenter, in which case I’d say: “phew, good thing you had a backup router that took over the traffic on that outage, right”??

However, it might be a nice feature in the update to let the user request automatic reboots after updates e.g. via checkbox in reforis somewhere.

@Radovan_Haban

The worst thing is that Turris is “able” to open it’s internal configuration UI to Internet “automatically” in case of update problems!

That sounds scary. But I will be only able to test that myself on Friday.

[moeller0]

@Radovan_Haban

I’ve Synology devices at home 8 years and I never experienced something like this…

Well, Synology is not based on OpenWrt to begin with. OpenWrt itself does not guarantee upgrades across major versions… However your reforis issue is not a core OpenWrt issue, reforis being a turris add-on. But I see your discontent and respect it, even though personally I fall into the team turris is overall doing an excellent job (in spite of occasional issues, so far they have always managed to fix things).

[jada4p]

TO 2016, HBS branch, 2 GB, 2x WiFi, HaaS, RIPE Atlas, Sentinel, lxc, simple config.

I was little bit afraid to allow update to OS 6.0, reading some trouble reports…

BUT: update went like charm, after reboot was both WAN/LAN WiFi working, web accesible… (To be sure I rebooted twice

All is working (or at least seems to work - HaaS, Ripe Altas, Sentinel, Netmetr, lxc, networking [as to networking, my config is very simple], reForis, LuCI).

There were/are some small glitches:

• Sentinel firewall logging failed; but after disabling and enabling it again in reForis it is OK now;

• some sensors were not found - maybe there is different naming schema, will check later;

• rainbow behave differently, have to investigate.

In pkgupdate console output (saved to file, if anybody from Turris team would be interested) there were number of “Command failed: Not found” errors/warnings. e.g.

• INFO:Running postinst of reforis-diagnostics-plugin-l10n-cs
  Command failed: Not found

and section of “ERROR:Failed operations:”

fix-omnia-leds-migrate/postinst: Command failed: Not found
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger:
grep: /sys/class/leds/rgb:wan/trigger: No such file or directory
Warning: activity setup failed for: wan
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-1/trigg
grep: /sys/class/leds/rgb:wlan-1/trigger: No such file or directory
Warning: activity setup failed for: wlan-1
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-2/trigg
grep: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory
Warning: activity setup failed for: wlan-2
Command failed: Not found

But, as I said, all seems to work (in my simple case).

Kudos to Turris team for their work and support!!!

As anybody who is working in informatics field for more time than initial learning already knows, no product - be it hw/sw - is without problems/bugs… and it is nearly impossible to test all possibilities. In case of such deep change, as from OS 5 to OS 6, one should expect some troubles… Fortunately, in most cases, they were mainly small glitches. And help from team and/or forum is within arm’s reach…

Again: Kudos to Turris team for their work and support!!!

[Leonardo]

Update fails in my Omnia running TOS5.4.4.

I approved the update in reForis and few minutes later I got a email with the update failure.
Rebooting TO did not help.

I manually executed pkgupdate, it retrieved all the information about the update. But it fails to download an ipk package due a resolving issue.

At every attempt the package is different, but I’m always able to download those packages with wget.

I’m able to ping repo.turris.cz with both ipv4 and ipv6.
I tried with both DNS resolver and forwarder.

I didn’t do any changes since 5.4.4 update.

Any recommendations?

[DIKKEHENK]

Interesting, since this TOS6 the cpu temp drops about 10 to 13 c… from 78 to 64

[maurer]

Omnia 2016 1G nowifi upgrade failed - boot loop. 2 attempts - both failed
Easily reverted to last snapshot.
I’ll hook up a serial adapter to get some logs in the next days.
Kudos to Turris team - I’m sure we’ll get everything straighten up soon

[multi.flexi]

Update failed on Turris 1.1. The kernel did not get updated, therefore Wi-Fi cards did not work, had to SSH into it and do pkgupdate and reboot.

[mionica]

Interesting one. After upgrading, I get loads of entries that look like

Oct 19 19:12:02 router dnsmasq-script[5182]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 3: import: not found
Oct 19 19:12:02 router dnsmasq-script[5182]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 4: import: not found
Oct 19 19:12:02 router dnsmasq-script[5182]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 5: import: not found
Oct 19 19:12:02 router dnsmasq-script[5182]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 6: from: not found

Now, I fully realize that my setup is unsupported (resolver set to use kresd, with dnsmasq running on port 54 and kresd forwarding lan requests to dnsmasq; also have adblock running), so this doesn’t qualify as a bug.

That said, any pointer on how to stop those messages from polluting the log would be great. Sure enough, the script exists, and it begins with #!/usr/bin/python3.
The cause seems to reside in /tmp/etc/dnsmasq.conf.cfgsomething, with a line saying

dhcp-script=/usr/lib/dnsmasq/dhcp-script.sh

but I’ve no idea whatsoever whom generates that call; also, in that particular script, there’s no reference whatsoever to any script in /etc/resolver.

Any ideas?

[Petr_Man]

I can confirm that this is happening. I get the reforris/luci choice screen when accessing the router on the external IP.
I have two port forwarding rules in place for port 80 and 443, which seem to be ignored and instead I get the reforris/luci choice.
EDIT:
I am also unable to find any firewall rule that would allow the web frontend to be accessed remotely, which leads me to suspicion that there is a general rule allowing all input somewhere in iptables.

[Ritchy]

It helped me with my problems:
Turris Omnia: disconnecting from electricity and reconnecting.
Turris 1 and 1.1: disconnecting from electricity and reconnecting + PUTTY, logging in and command pkgupdate and when finished command reboot
Including the problem No wireless cards were detected on the router.
Now is my three router works fine.

[martin131]

Turris 1.0
I updated my router to TOS 6 and after update openvpn was not working and kernel was on 4.14 version. So I rollbacked to latest working version via Schnapps. Then i didn’t clicked any button and after few hours later TOS 6 was installed again. I have enabled auto updates with confirmation. Very bad update

edit:
I have disconnected from power my Turris twice then I was able to connect to Turris from LAN. So I have checked kernel version and I was still on 4.14. Then I tried pkgupdate via SSH and everything seems to be working now.

[dhopfm]

@Petr_Man

I get the reforris/luci choice screen when accessing the router on the external IP.

If you try to access your WAN IP from a client on the LAN, then this is expected. It shouldn’t work from the WAN side, though. Where are you connecting from?

@Petr_Man

leads me to suspicion that there is a general rule allowing all input somewhere in iptables.

iptables -L -v should help clarify that unambiguously.

[Petr_Man]

I tried this remotely from a different device. The UI is accessible remotely.
From my perspective also having the UI accessible on the WAN IP from LAN is not expected behavior, especially since I have put a port forwarding in place, which should hit first.

[Hlusta]

Thank ypu!
pkgupdate worked for my Turris 1.0 (2.4 + 5 GHz wifi).

[dhopfm]

You could look at (or share) the output of iptables -S | grep -e input_wan_rule -e zone_wan_input -e zone_wan_src_REJECT specifically.

@Petr_Man

From my perspective also having the UI accessible on the WAN IP from LAN is not expected behavior, especially since I have put a port forwarding in place, which should hit first.

Firewall (including port forwarding) rules primarily work based on interfaces. The port forwarding rule on your router probably is only defined for traffic entering through the WAN interface so there’s no conflict with any traffic originating from the LAN interface. The fact that the WAN IP is accessible from the LAN side is not uncommon, search for NAT hairpinning if you’re interested.

[Petr_Man]

@dhopfm

Firewall (including port forwarding) rules primarily work based on interfaces. The port forwarding rule on your router probably is only defined for traffic entering through the WAN interface so there’s no conflict with any traffic originating from the LAN interface. The fact that the WAN IP is accessible from the LAN side is not uncommon, search for NAT hairpinning if you’re interested.

However, there is also NAT reflection, which is enabled for my forwarding rules by default and which also perfectly worked before 6.0. I could access a server on the LAN via the forwarded port regardless if I was on LAN or outside.