Switch chip not working?

anon50890781 · January 19, 2019, 3:40pm

With this conf it was expected that that VLAN to work

Summary

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 3 5'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6'
	option vid '2'

however eth0.1 and eth0.2 are no shows with ls -l /sys/class/net or ifconfig or ip l or ip a.

the chip is also absent from being listed with lspci

Summary

00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
03:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)

Since the chip’s driver mvsw61xx is supposed to be statically baked into the kernel (CONFIG_MVSW61XX_PHY=y) none of the kernel module probing tools, e.g. modinfo | modprobe, are applicable.

However, here it gets confusing as https://repo.turris.cz/omnia/lists/base.lua showing (which does not make sense)

– Critical minimum
Install(“kmod-switch-mvsw61xx”

which is a dynamic kernel module (as opposed to the aforementioned static kernel driver) and which should provide mvsw61xx.ko by its definition. Yet that module is not traceable on the node (or in any medkit version for that matter).

With eth0.1 and eth0.2 being no shows and the chip not listed with lspci either it seems that the switch chip is not working. Or what am I missing?

protree · January 19, 2019, 3:52pm

eth0.1 and eth0.2 would appear if you set switch port 5 (connected to eth0) tagged like this (example only for vlan 1):

config switch
option name ‘switch0’
option reset ‘1’
option enable_vlan ‘1’

config switch_vlan
option device ‘switch0’
option vlan ‘1’
option vid ‘1’
option ports ‘1 2 3 5t’

In your config ports 5 and 6 connected to eth0 and eth2 are untagged(!) so there is no vlan known to CPU. Your vlans only exist on the switch chip.

Nevertheless I think your config should work if you attach according interfaces to eth0 and eth2 (NOT eth0.1 and eth0.2).

anon50890781 · January 19, 2019, 4:01pm

Thanks for the response but tagging (port 5 or any port) is not related to the creation of the actual iface eth0.1 or eth0.2, if I am not mistaken.

protree · January 19, 2019, 4:04pm

Set port 5 tagged and I beg eth0.1 will show up if I am not mistaken (Or I don‘t fully understand what you mean)

Edit: eth0.1 should show up in physical settings in interface settings in LuCi. If you connect an interface to eth0.1 it should then show up in ifconfig,too

protree · January 19, 2019, 4:14pm

Think about switch chip in TO as a dedicated managed switch with two Interfaces from TO (eth0,eth2) attached to ports 5 and 6.

Configuring vlans on the switch doesn‘t necessarily mean they show up on the CPU. VLAN Interfaces on the CPU only show up if communication between switch-chip and CPU is tagged.

anon50890781 · January 19, 2019, 4:34pm

LuCI is not really the tool to depend on querying the actual status/presence of ifaces. Instead use ls -l /sys/class/net or ifconfig or ip l or ip a. And none is showing eth0.1 or eth0.2.

VLAN tagging is performed by putting the VLAN ID into a header/frame to identify which network it is present in. How could that possibly create an iface?

As for for any other hardware iface (layer 2) it requires a static kernel driver or dynamic kernel module or for a software emulated solution a userland app like openvswitch

protree · January 19, 2019, 4:58pm

Yes of course, OpenWRT creates the interfaces for you. You just have to configure it the right way.

This is how i configured a “DMZ” Interface with VLAN ID 3. It’s fully working on TO since start and eth0.3 is shown by ifconfig…

/etc/config/network:

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '3'
        option ports '0 5t'
config interface 'dmz'
        option type 'bridge'
        option proto 'static'
        option ifname 'eth0.3'
        option ipaddr '192.168.122.1'
        option netmask '255.255.255.0'

root@MarPort:~# ifconfig
br-dmz    Link encap:Ethernet  HWaddr D8:58:D7:00:51:BA
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::da58:d7ff:fe00:51ba/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:30598 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54827 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6183117 (5.8 MiB)  TX bytes:73570989 (70.1 MiB)
[...]
eth0.3    Link encap:Ethernet  HWaddr D8:58:D7:00:51:BA
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:30598 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54997 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6183117 (5.8 MiB)  TX bytes:73582169 (70.1 MiB)

As long as you didn’t remove it I don’t think there is any module missing on your TO…

protree · January 19, 2019, 5:03pm

Sorry I think I understand why we misunderstand us now:

config interface ‘dmz’
option type ‘bridge’
option proto ‘static’
option ifname ‘eth0.3’
option ipaddr ‘192.168.122.1’
option netmask ‘255.255.255.0’

This is the part which configures the interface. You didn’t set this up, you only set up the VLAN-config on your switch-chip (See your first post).

anon50890781 · January 19, 2019, 5:14pm

That is the point - you are using a layer 3 bridge which should not be required for a VLAN to work on layer 2. Switch from bridge to direct link and there is no VLAN connectivity…

protree · January 19, 2019, 5:19pm

Like this? this is also working fine…

/etc/config/network:
config interface 'dmz'
        option proto 'static'
        option ifname 'eth0.3'
        option ipaddr '192.168.122.1'
        option netmask '255.255.255.0'
config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '3'
        option ports '0 5t'

root@MarPort:~# ifconfig
eth0.3    Link encap:Ethernet  HWaddr D8:58:D7:00:51:BA
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1806 (1.7 KiB)  TX bytes:1317 (1.2 KiB)

EDIT: bridge is onlly there because I added a WLAN-Interface to it. As you can see vlan-communication doesn’t depend on it. I can also ping my devices. Or do I still misunderstand you?

anon50890781 · January 19, 2019, 5:24pm

It does not my end, whether 5t or not. eth0.1 or 0.2 are not present. And lspci is not listing the switch chip.

protree · January 19, 2019, 5:24pm

Output of lspci:

root@MarPort:~# lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6820 (rev 04)
02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
03:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)

→ Same as your’s. Still it’s working for me

protree · January 19, 2019, 5:28pm

Post your /etc/config/network and output of ifonfig. I am pretty sure there is just some misconfiguration

anon50890781 · January 19, 2019, 5:29pm

Since I started this from 3.11.2 medkit I was wondering whether your device been updated from stock when you procured it or whether you remember the version of the last medkit installation done perhaps?

protree · January 19, 2019, 5:31pm

I did a medkit reset some months ago (maybe 5). There should be a btrfs snapshot maybe with some metadata of it, shouldn’t it? I take a look

EDIT:

root@MarPort:/mnt/btrfs# mount -o ro /dev/mmcblk0p1 /mnt/btrfs/root/
root@MarPort:/mnt/btrfs/root# ls -hl
[...]
drwxr-xr-x    1 root     root         106 Oct 16  2017 @factory

cynerd · January 19, 2019, 5:44pm

@anon50890781 chip is not on PCI so it is not visible when you use lspci.

RTFM: https://doc.turris.cz/doc/en/howto/vlan_settings_omnia

anon50890781 · January 19, 2019, 7:02pm

Well, that is where it gets confusing of why it need CPU tagging for the OS being able to show the switch ifaces.

The issue I am facing now is that enabling tagging the CPU via LuCI ceases all communications with the router. It works ok however by manually editing the network via ssh and then restarting the network from the cli.

protree · January 19, 2019, 7:12pm

VLAN 1&2: LAN (Default Turris Omnia setup as described here: https://doc.turris.cz/doc/en/howto/vlan_settings_omnia)
VLAN 3&4: Custom VLANs with custom subnets (3 as described in my previous posts)

Maybe this helps… I never lost contact to TO when setting up a new VLAN

protree · January 19, 2019, 7:21pm

When you change CPU Port from untagged to tagged for VLAN1 (LAN) you also have to change iface of LAN interface from eth0 to eth0.1 before applying the changes

anon50890781 · January 19, 2019, 7:41pm

The setup/usage is clear. Not clear been the visibility of the VLANs if the CPU is untagged.

I am aware of the changes that needs to be done prior committing the changes, which as said works fine via ssh/cli but not via LuCI for some reason. Which I am not going to investigate.