Turris OS 4.0.3 is released!

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_CGROUP_BPF is not set

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…

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


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 @anon50890781’s post got hidden?
There is actually no detailed documentation site about DSA handling in turris wiki or am I mistaken?
Therefore the link @anon50890781 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 (@anon50890781) flag his post and the other one as off-topic and that’s why they were temporary hidden.


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]
  • 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


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 for the percentage of memory usage:
/usr/bin/kresd -c /tmp/kresd.config -f 1 /tmp/kresd -a 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 --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.


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.

Hi Pepe,

I try change Turris 1.0 to OS 4.x. When i use schnapps import -f turris1x-medkit-*.tar.gz. I get this info schnapps import -f turris1x-medkit-latest.tar.gz Import takes one argument which is snapshot info file! Actual tarball has to be next to it!
best regards,


May I know which version of Turris OS and schnapps do you have installed on NAND? You need to update your router to the latest version, which includes a new version of schnapps.