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) 
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.
- 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].
- UCI | LuCI does not support parsing:
ip l s dev ${bridge name} ty bridge vlan_filtering [ numeric value 0 | 1]
and/orecho [ 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
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.
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,
Jirka
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.