Hi there. I recently got zbtlink we-1602 device with dual-sim. I already have compiled my firmware and installed it in my device fine. Everything work just fine, except STP. lan1, lan2, lan3 and lan4 are in one bridge (br-lan). STP is on
root@OpenWrt:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.f85e3c316c24 yes lan4
lan2
lan3
lan1
I plugged one end of patch cord in lan1 port, the other - in lan2 port. After that, my device stop to response in 5-10 seconds. I simply don't know how to solve not working STP issue. No answer is found in OpenWRT wiki. Kernel version is 5.10
root@OpenWrt:~# uname -a
Linux OpenWrt 5.10.153 #0 SMP Thu Nov 10 15:38:06 2022 mips GNU/Linux
Here is my /etc/config/network file
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fdb6:a2d5:86e9::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
option stp '1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
Traffic between two LAN ports is hardware switched, bypassing the Linux kernel. Most consumer hardware does not include loop detection, so a loop will cause the switch to jam up with looped packets and DoS the network.
STP is a software feature that is only active on packets that pass through the kernel.
I got next logs after the loop creation with patch cord
Fri Nov 11 01:21:45 2022 kern.info kernel: [35074.183948] br-lan: port 1(lan1) entered blocking state
Fri Nov 11 01:21:45 2022 kern.info kernel: [35074.189211] br-lan: port 1(lan1) entered listening state
Fri Nov 11 01:21:45 2022 daemon.notice netifd: Network device 'lan1' link is up
Fri Nov 11 01:21:45 2022 kern.info kernel: [35074.195368] br-lan: port 2(lan2) entered blocking state
Fri Nov 11 01:21:45 2022 kern.info kernel: [35074.200613] br-lan: port 2(lan2) entered listening state
Fri Nov 11 01:21:45 2022 daemon.notice netifd: Network device 'lan2' link is up
Fri Nov 11 01:21:46 2022 kern.info kernel: [35075.015195] br-lan: port 2(lan2) entered blocking state
Fri Nov 11 01:21:48 2022 kern.info kernel: [35076.419264] mt7530 mdio-bus:1f lan2: Link is Down
Fri Nov 11 01:21:48 2022 kern.info kernel: [35076.424208] mt7530 mdio-bus:1f lan1: Link is Down
Fri Nov 11 01:21:48 2022 kern.info kernel: [35076.429861] br-lan: port 2(lan2) entered disabled state
Fri Nov 11 01:21:48 2022 daemon.notice netifd: Network device 'lan2' link is down
Fri Nov 11 01:21:48 2022 daemon.notice netifd: Network device 'lan1' link is down
Fri Nov 11 01:21:48 2022 kern.info kernel: [35076.436310] br-lan: port 1(lan1) e
I guess STP actually works and it's hardware fault? I'm really confused, because with kernel 5.4 loop doesn't cause interface getting stucked
It's not a hardware fault, it's a hardware and/or DSA driver limitation that the switch can't handle loops. DSA doesn't yet necessarily activate all functions that are available on every hardware. Don't create Ethernet loops.
You would have to test with two (2)ntermediate switches. This only shows the connection going up/down. Which I expect in signaling when the device realizes it's its own MAC requesting connection to itself.
I'm referring to the signaling at hardware level when establishing the Layer 2 connection. This this prevents Layer 2 establishment, you're hence leftover with just hardware connect not working (i.e. at Layer 1 - hardware).
This created the Layer 1 fault in question.
We can put "fault" in quotes and use your wording too.
Thus, for true STP tests I need second device... And ethernet loop fault is not Layer 2, but Layer 1 problem and it's related to DSA driver problem overall?
You have to create paths with switches so that there's mutiple layer 1/2 paths from A, thru the OpenWrt and anothet switch, separated said client/switch X.
See images here:
Managed switches have a MAC so @mk24 warning may apply to this setup with a DSA Kernel - but i think this applies to any "client" machine on Ethernet (i.e. it sees its MAC on wire and hence fails).
The results are: I can't ssh any device, one host (PC-1 or PC-2) barely can ping another. If I unplug one of the parallel connected wire, everything works fine. Surprisingly, if i change WE1602 to WG3526 everything works fine...
Disregard my inquiry. I understand now that you're attempting with only two devices despite my information (and images form Wikipedia in the provided link).
(There's still only a path thru the same 2 devices - you have to create at least another path via a 3rd device. That obviously requires more equipment, as I noted already.)
Managed switches have a MAC so 