Turris OS 4.0 beta1 is released!

Would you please send it to us to email address tech.support@turris.cz? All inquiries about Turris OS 4.0 are handled with high priority. You will receive a reply by Monday at the latest.

OK, took the plunge and installed 4Beta1. Upgrade went without problems. Configuration with new Foris is more stable than with the old one.

Al seems to work OK with the exception of PnP. Clients that work without problem under 3.11 can’t configure the router under 4Beta1. Is this known?

I ran against the problem of ntp preventing the beta 1 to be installed. It had some sort of a collision. I had installed ntpd so i could use the Omnia as a time server for my other network devices to point at.

Collision

Updater selhal:

[string “transaction”]:326: [string “transaction”]:153: Collisions:

• /sbin/ntpd: busybox (new-file), ntpd (existing-file)

I removed both of these and i could update.

ntp-utils
ntpupdate

EDIT: Btw, i can confirm that systemctl still does not work on a existing Ubuntu 18.04 LXC.

systemctl start deluged.service

root@K-Router-LXC:~# systemctl start deluged.service
System has not been booted with systemd as init system (PID 1). Can’t operate.

Got PnP working. The service “miniupnpd” is not started despite that “start upnp service” is selected in Luci. A manual start of the service corrects this.
Didn’t we have a similar issue with one of the 3.11 version?

Otherwise 4Beta1 seems to run fine.

We run something like this at work. For this case, DNSSEC will always break since all the DNS is redirected to a single or a handful of IPs for every hostname.

Created issue on our Gitlab - https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/374.

This one could happen in some situations. However, it should be stable in all of our releases. What you can notice now that there’s a newer version of Foris & friends in Turris OS 4.x, which may include some fixes for bugs, which was reported to us in Turris OS 3.x. It willl be same in Turris OS 3.11.5 once we release it. It is possible that there will be even a newer version. This all depends when we release a new version from our development branches.

The described how to in Installing ntpd on TurrisOS? doesn’t work for you? However, we will look at it if there’s anything what we can do about it.

@miska is working on it! I can not tell if it will be included in the upcoming release as we would like to test it as much as possible as we want to send it OpenWrt as well. We’re working to have the latest LTS version of LXC which is 3.0.3 supported until June 2023 instead of 2.1.1, which is no longer supported by upstream and this old version is in OpenWrt.

There must be a different issue as the fix is included in OpenWrt 18.06 and also in Turris OS 4.0 as it is based on top of that release.

Guest WIFI is missing IPv6 config. I only went through the Wizzard, no other config changed.
IPv6 assignment length is Disabled y default on GUEST_TURRIS interface.
It was the same in version 3.x.
My IPv6 provider is 6in4 tunnel by Hurricane, but I don’t think this would be the cause.

Well, the only thing i did was a 4 LED reset, went through the Foris setup (as router), and checked the “Luci extensions” at the end (wait for installation of course) . After enabling “start upnp service” in Luci I had to manually start “miniupnpd” to get PnP to work.
I can’t imaging I did something to prevent the miniupnpd from automatically running.

I don’t know if it is important but i just noticed it.

When using a network scanner TO with 3.11.x always reported the MAC vendor as “CZ.nic z.s.p.o.”.
Since upgrading to 4Beta1 it reports it as “Compex Systems Pte”.

Oh… now, it’s very clear to me, where is the issue. The enable it means that it will enable service autostart (after boot), but it won’t start the service right now. If you want to the service right now, there’s button start.

We don’t have support for IPv6 in Guest Wi-Fi, yet. It is possible that in the future, we will add it, but for now, it doesn’t have any high priority. However, there is already created an issue for it
https://gitlab.labs.nic.cz/turris/foris-controller/issues/70 and it means that we won’t forget about it.

We have been able to reproduce it, thank you for reporting it to us. This is related to kernel stuff. Unfortunately, we will solve the reported issue with a low priority. I’m going to create an issue in our Gitlab, where it can be tracked.

1 Like

Well i thought, that on first eth0 is linked LAN0-LAN3 and second eth2 is linked LAN4 (eth1 linked to WAN).

Its not like that?

Could not get odhcpd to listen on port 67 for ipv4 dhcp queries (dnsmasq disabled/stopped/removed). Lodged as gitlab issue #376.


sorted - besides setting maindhcp to 1 it requires to set also dhcpv4 to server in the iface dhcp section

config dhcp 'iface'
        option dhcpv4 'server'

Excellent job!
Updated from tos 4 alpha5 yesterday without any issues

Mox A and D module

1 Like

That is default setup in Turris OS 3.x. You could change that in Luci interface. In Turris 1.x are all lans connected trough eth0 and eth1 (this time connected to switch) is not used to connect to switch. Eth2 is wan.

I think the pictures are the best … :slight_smile:
Turris 1.x - https://doc.turris.cz/doc/cs/howto/vlan_settings_turris
Turris Omnia - https://doc.turris.cz/doc/cs/howto/vlan_settings_omnia
Turris MOX - ??? - why???

I undrestand, but it means, that in standard setup, after Turris 4 Beta install on Omnia, LAN4 stops working.

No that is not what it means. Look in to picture @Nones linked to. Lan4 is connected to switch. Switch in default was configured to connect eth2 to lan4 directly while switching rest of lan ports to eth0. That was just a configuration. Setup in Turris OS 4.x+ is that you are no longer able to configure port6 on switch chip so eth2 is unused.
Also note that for confusion in TOS 4.x+ eth2 is swapped with eth1. It is just marking but it might confuse you.

Mox does not have any special setup. It is just switch chip chain. It will be documented in schematics (once we release them).
Those schemes should no longer be required because all should be configured automatically by DSA. DSA knows this topology and depending on bridge setup it configures switches.

1 Like

OK, thanks to explanation.
But documentation is missing … :frowning:

Thanks for this explanation. One point I still don‘t fully understand is:

Is DSA really configuring the switch so that switching is handled on switch hardware? Or is a configured bridge from now on only a software bridge where all traffic passes CPU?

e.g. you have a LAN and a GUEST subnet as separated vlans. You create a bridge for LAN with vid1 over LAN Ports LAN1&2 and a second bridge for GUEST with vid2 over LAN Ports LAN3&4. There is a route between them on the Omnia so they communicate with each other (as desired depending how you set up firewall) and both can access WAN over Omnia.

LAN -> WAN, GUEST -> WAN, LAN -> GUEST and GUEST -> LAN all pass CPU (Layer 3 Communication, expected)

But is LAN -> LAN and GUEST -> GUEST Communication (Layer 2) directly handled by Switch Chip configured by DSA? Or does this traffic still pass CPU because of DSA abstractiom layer?