Turris OS 4.0.3 is released!

I would definitely like to try it on my blue Turris 1.0. But I got a lot of functionalities working on my current TOS 3 like LXC, pihole, My first question is is there LXC working with debian PPC ? Is CGROUPS and other options included and compiled into kernel for LXC ? Without LXC I could not use PIHOLE and bunch of other packages that I run on debian containers.
Second question how to try it safe way ? Should I rather take SD card out and make copy of it and run test on copy to prevent any damage of my working system.

I tried schnapps import -f turris1x-medkit-*.tar.gz and first get some error message that says no factory snapshot then I run same command again and then it say factory was imported and I was even able to mount it with schnapps mount factory. Even schnapps list does not show factory snapshot. Are there any other more “hidden” snapshots created by default ?

How to do migration the best way ? My plan is to export opkg list-installed to file and delete versions in excell file and add opkg install command for each line, then run it as script on booted TOS 4 to make sure all packages will be installed that I had on TOS 3. Then copy everything from original TOS 3 folder /etc/config/* to new system with also few other configs from /etc that are not covered by openwrt /etc/config. Will it be sufficient ? Or what other approach is recommended ?

To get back to TOS 3 is just schanpps rollback to TOS 3 snapshot enough ? I suspect that full migration will take me some time so I will need to switch between TOS 3 and TOS 4 for some time untill I am happy with all the working configuration on TOS 4.

Which packages are not on TOS 4 ? Noticed that you abandoned CUPS ? How about shellinabox ? I use it a lot to access my Turris and I was not able to compile it on openwrt master for x86 due to some problems with new version of OpenSSL.

Will it be also possible to compile TOS 4 and cherry picked packages on newer distro like debian buster that I use ? Or is still something archaic necessary ?

Hello,

Unfortunately, the DDNS package isn’t correctly packaged in OpenWrt and there are some issues with postinstall script and it seems that updater might run for some time, but it waits till the process timeouts before it kills postinstall script. More details can be found in this issue:

Did you receive the notification just once? I ask if you had a temporary Internet outage. Updater checks every 4 hours if there is a new update available.

Can you check if the Updater isn’t running in the background?

If you have running LXC container on your router, I suggest doing backup. It should work to bring the existing once from Turris OS 3.x to Turris OS 4.x, but I didn’t try it as I am not using LXC on Turris 1.1 router anymore. I had it for Tvheadend, but I compiled it for OpenWrt.

Otherwise, to setup a new one can be problematic as powerpcspe were removed from Debian ports.

Thread in Czech section:


Anyway for more details why it was removed you can read e-mail from Debian maintainer of powerpcpse https://lists.debian.org/debian-powerpc/2019/05/msg00128.html

Here is kernel configuration on Turris 1.1, which is running Turris OS 4.0.3.

root@turris:~# zcat /proc/config.gz | grep CGROUP
CONFIG_CGROUPS=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_BPF is not set
CONFIG_CGROUP_DEBUG=y
CONFIG_SOCK_CGROUP_DATA=y
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
CONFIG_NET_CLS_CGROUP=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y

More options will be enabled in Turris OS 5.x according to this pull request, which I have on review. Once it is merged, it should be quite easier to have/run Docker on Turris Omnia, Turris MOX.
Not sure, if they will be backported in Turris OS 4.x. Most likely I doubt.

Package shellinabox wasn’t and still isn’t part of Turris OS / OpenWrt. If you would like to have it in OpenWrt, you will need to send a pull request to packages repository. In the morning, I take a look, why you couldn’t compile it. You are right that it is related to a new version of OpenSSL, but there is a year pending pull request, which was not accepted nor reviewed by developers of shellinabox and the guy who sent the PR is taking care of OpenSSL in OpenWrt. So, you just need to download it as a patch and put it to patch folder inside shellinabox.

About CUPS, it is complicated. More answers later…

Edited:
Did a clean installation of 4.0.3 on my MOX (modules P,A,B with installed WLE900VX and external antennas) and WiFi on module B is not working after some days of uptime (see –>post below).
I didn’t manage to get SDIO-WiFi working yet (see other threads on this topic).

former post

Did a clean installation of 4.0.3 on my MOX (modules P,A,B with installed WLE900VX and external antennas) and it works as expected.
Still not working: SDIO (see other threads on that topic, as it is firmware issue, not OS itself).

By flashing firmware to OS 4.0.3 I was not able to restore the user settings saved under OS 3.x. Doing this caused LAN ports without any local connectivity, so I needed re-reflash and doing the complete configuration from the beginning. Using the guided configuration is easy and quick. Nevertheless for advanced configuration it seems a lot has changed, especially in the Luci Interface. Most of the changes are fine for me. But the vlan/switch configuration got some changes, so I was not able to recreate my old settings. For example the WAN port is now assigned to “eth2” (was before eth1, while eth0+eth2 were on LAN side). Also the menu entry for the switch configuration disappeared in Luci, it was helpful for creating additional VLANs. Now adding VLANs is only possible via SSH editing the /etc/config/network file. With that the menu for the switch settings also comes back, but always with warning of improper switch config. Also the WAN port doesn’t appear there. All this is much more complicated and so it has failed for me yet, maybe because new VLAN settings seem to conflict with the given pre-configuration (perhaps interface option “_turris_mode ‘managed’”, likely others too).

Would it be possible either to give back the easy opportunity of Switch/VLAN configuration via Luci and/or would you provide a example for the /etc/config/network file? The description from the turris team at howto/vlan_settings_omnia does not work with the Turris OS 4.0.3 and should be updated.

There are some threads in this forum with regard to VLAN configuration in TOS4+.x (cue DSA).

The TOS documentation is not yet reflecting the changes [1] and LuCI support is only partial [2] (lacking support for bridge related VLAN commands)


[1] https://gitlab.labs.nic.cz/turris/user-docs/issues/22
[2] https://github.com/openwrt/luci/issues/2798

2 Likes

Thanks for the quick answer. As the issue of missing vlan config in Luci is sustaining, I would appreciate the turris geeks could provide an example for the manual configuration of vlans in etc/config/network, for instance tagging of port “LAN4” with 2 or more tagged vlans.

Nevertheless, I just tried some things and found an easy possibility for a simple vlan tagging: In Luci Interface under “Network/Interfaces” just “add new interface” of type “unmanaged”, and assign this to a new interface (“cover the following interface --> create new …”); in my case as “lan4.3”, that establishs a new tagged vlan “3” on the lan4 port, in addition to the existing untagged. Then I was able to assign or bridge this new dummy-interface, in my case to a new created wireless network. grafik
My purpose was providing an external network (which is not originated in turris router) by the wireless devices of the Turris router. This works fine now.

My workaround did only work for one single tagged vlan, not for more taggings on the same port. So I’m still hoping for advice for network settings via ssh…

Can someone please explain, why @n8v8r’s post got hidden?
There is actually no detailed documentation site about DSA handling in turris wiki or am I mistaken?
Therefore the link @n8v8r posted adds definitely value to this topic and he is right in what he is stating…

Yeah, I agree with that. Those posts shouldn’t be hidden, but the author (@n8v8r) flag his post and the other one as off-topic and that’s why they were temporary hidden.

Proof:

On the other hand, those two posts might be off-topics and can be moved to separate thread.

There is no need to create an unmanaged interface for each tagged/untagged port. Just scroll to the bottom of the list you screenshotted (Bridged interfaces in Physical settings of corresponding interface) and add e.g. lan4.3 in the custom field at the bottom of the list. You can add as many tagged/untagged ports as you wish (as long as it is possible of course) :slight_smile:

1 Like

It was my opinion that those posts are off-topic (4.0.3 release) and should be split/moved to one of the existing DSA related threads and thence invoked the flag in order to notify a forum moderator to take a look (however the flag function does not allow to state a reason/suggestion when invoking a flag).
Because now this thread seemingly turns into another DSA related discussion whilst covered elsewhere already.


As of today:

Brief summary about the current state.

  1. UCI | LuCI does support parsing:
  • ip l a l ${interface name} n ${interface name}.{virtual extension} type vlan id [numeric value]

which always creates a virtual interface that is 802.1q tagged. It can be leveraged with the node’s upstream and downstream interfaces. Removal of such virtual interface also works.
Managing tag/untag state with related VID/PVID of existing downstream interfaces does not work with the ip command by design [3].

  1. UCI | LuCI does not support parsing:
  • ip l s dev ${bridge name} ty bridge vlan_filtering [ numeric value 0 | 1]
    and/or
  • echo [ numeric value 0 | 1] > /sys/class/net/${bridge name}/bridge/vlan_filtering

either of which is leveraged to toggle VLAN filtering (for bridge isolation) on or off.

  • bridge v a dev ${interface name} vid [numeric value] [options]
  • bridge v d dev ${interface name} vid [numeric value] [options]

used for the management of 802.1q tag/untag state and related VID/PVID of downstream interfaces (lan and bridge) and does not create any virtual interface.

Currently it requires a script coded by the user to retain VLAN tag/untag states with VID/PVID between node boots, respectively a hotplug script for dynamic VLAN state management. And reading from [2] this is not going to change anytime soon.


Just as an example

config interface 'vlan1'
	option ifname 'lan4.1'

and add whatever else is required as remainder, e.g.

option type 
option bridge_empty 
option proto 

[3] https://www.linux.org/docs/man8/ip-link.html

2 Likes

I would also suggest to stop using LXC on Turris 1.x. I already did it, after years of using LXC on Turris 1.0, I have moved my container to Raspberry Pi 4 with 4GB RAM. I am quite happy with it. The only downside is missing AES-NI (hw crypto). I did not try VPN, but I tried borg backup wit encryption enabled. It was very slow.

BTW @Twinkie were you successful with running LXC on the mashine you got from Aliexpress?

I also have a question regarding PIHOLE. What is the benefit of PIHOLE over adblock package in Openwrt? Both are doing DNS fitering, but adblock does not need separate LXC. Of course, adblock does not have fancy webgui with analytics, but you can still manage adblock (including custom whitelists and blacklist) in Luci.

I have to take back my formerly possitive conclusion:
It seems there is a problem with the WiFi on module B, but this bug is older than 4.0.3 (have a look –>here).

  • WiFi not reachable anymore
  • high load
  • no memory left
  • syslog flooded with
[766739.132983] ath10k_pci 0000:00:00.0: wmi mgmt tx queue is full
[766739.139376] net_ratelimit: 11 callbacks suppressed
[766739.139407] ath10k_pci 0000:00:00.0: failed to transmit packet, dropping: -28
[766739.152151] ath10k_pci 0000:00:00.0: failed to submit frame: -28
[766739.158620] ath10k_pci 0000:00:00.0: failed to transmit frame: -28
[766739.165852] ath10k_pci 0000:00:00.0: wmi mgmt tx queue is full

I had to restart MOX to get full usability back again.
I’ve sent diagnostics to tech.support@turris.cz.

I will reply you here as even it is not much related. Yes I succeed wit running LXC on x86 machine from aliexpress by compiling custom kernel (unfortunatelly LXC options are onot embeded in compiled version at openwrt site) but god I struggled a lot with that as I been only able to compile 4.19 kernel from master and master is updated every week so you get all packages and kmods updated every week and hence you are unable then to install older packages due to kmod’s version incompatibility. It is kind of hell. My original plan was to use stable 18.06.3 or 18.06.4 but it has 4.14 kernel and I was unable to compile kernel witl LXC options enabled. So far I was unable to resolve those situation as I did not not had time to fiddle around this this time it is quite frustrating and excessively time consuming. Also my orginial idea to replace turris with this x86 device went bust after I realized that when I put insided the Compex 802.11ax card wifi speed get degraded once you connect first 802.11ac device. My plan is to get on 19.07 stable version once finally released to be able download and install packages from repo and build custom kernel with LXC options. If that succeed I may want to use this device as main router as it is has AES-NI and definitely way more power for my needs.Another options is to go on debian distro instead of openwrt. I also realized that that Compex 802.11ax card is not supported under Windows. Currently I put 240GB and have partitions with windows, debian, ubuntu, openwrt and data partition to exchange data between. My overall impression is that I really admire the work of CZ.NIC guys at openwrt as it is huge work to make such device running when opensource approach leads to so many difunctions that has to be solved again and again.

Wow, it didn’t take long until memory was eaten up again:


Can you please tell me, why MOX is using that much memory?! I am using it just as a dump ap, SDIO is uninstalled due to non-usability, the only packages I installed where netperf and iperf and those are not in use right now…
It’s really sad I spent that much money on a non-perfoming device - have a look at a WRT1900AC that is used quite equally after 163 days of uptime:

I had a look at https://192.168.1.6/cgi-bin/luci/admin/status/processes for the percentage of memory usage:
/usr/bin/kresd -c /tmp/kresd.config -f 1 /tmp/kresd -a 0.0.0.0 53 -a :: 53 -k /etc/root.keys : 8%
mosquitto -c /var/etc/fosquitto.generated.conf: 1%
{foris-ws} /usr/bin/python3 /usr/bin/foris-ws -a ubus filesystem --host 127.0.0.1 --port 9080 mqtt --mqtt-host localhost --mqtt-port 11883 --mqtt-passwd-file /etc/fosquitto/credentials.plain: 5%
{foris-controlle} /usr/bin/python3 /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock mqtt --host localhost --port 11883 --passwd-file /etc/fosquitto/credentials.plain --controller-id 0000000D3000755E: 8%
{foris-controlle} /usr/bin/python3 /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock mqtt --host localhost --port 11883 --passwd-file /etc/fosquitto/credentials.plain --controller-id 0000000D3000755E: 6%
{foris-controlle} /usr/bin/python3 /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock mqtt --host localhost --port 11883 --passwd-file /etc/fosquitto/credentials.plain --controller-id 0000000D3000755E: 6%
{foris} /usr/bin/python3 /usr/bin/foris -s flup -a config -b mqtt --mqtt-host localhost --mqtt-port 11883 --mqtt-passwd-file /etc/fosquitto/credentials.plain --mqtt-controller-id 0000000D3000755E: 7%
{foris-controlle} /usr/bin/python3 /usr/bin/foris-controller -b openwrt -C /var/run/foris-controller-client.sock mqtt --host localhost --port 11883 --passwd-file /etc/fosquitto/credentials.plain --controller-id 0000000D3000755E: 8%

So this is really not understandable:

  • this MOX is used as a dump ap, therefore kresd is not in use!
  • I really don’t use foris at all!

But still it is eating up together 50% of the memory!
On plain OpenWrt it is 8 percent process memory usage and another 11% on temporary files!
Without someone giving a good explanation I am really close to giving up on MOX.

Hello,

then at least you/me aren’t alone with this topic.
I have exactly the same phenomenon, after a very short time the memory is full and I get a message per mail that the updater cannot run anymore because “out of memory”.
I also use 90% of the standard configuration, first I thought about sqm and/or adblock but no improvement.
I have reduced the services bit by bit but it runs full again and again.
I hope it’s just a stupid bug in version 4.0.3, because you can’t use the device properly with that!

{Suricata-Main} /usr/bin/suricata -c /etc/suricata-pakon/suricata.yaml --pidfile /var/run/suricata/suricata.pid --af-packet=br-lan --af-packet=br-guest_turris
causes 16% memory usage the rest is similar to yours.

Maybe someone has a logical explanation why after a few minutes 512MB of RAM are almost full?

Best regards!

Is that a definite thing? Will there be no samba4 in TOS 4.x ever?

Yes. You can take a look for example in my post, where I explained it.

Anyway, samba4 is and will be included in the upcoming OpenWrt release 19.07 (currently in RC2).

1 Like

haveged seems to be using a lot of CPU for me on this release.

I’m using an omnia, flashed to 4.01 and then upgrading itself.