I tested the latest master on my 3 Zyxel devices, one for each SoC
generation, the GS1900-10HP, the GS1900-48 and the XGS-1210-10. They got
their IP addresses via DHCP on port 1 using the default network setup. I
then tested pinging, multicast (VLC) and iperf between different
non-management ports (2 and 3) and for multicast verified that nothing
could be seen on the router's CPU-Port nor the management PC. I did not
test anything specific to VLAN. I merely verified via "bridge fdb"t that
the entries in the forwarding table now use the vlan as forwarding ID
together with the target MAC address. Before that they were using a
fixed and very strange forwarding ID (4031 on the 8380) together with a
MAC-address. At the moment I do not have access to these devices (in
summer house) only a buggy DLink DGS 1210-10P, that does not want to
bridge between ports with OpenWRT.
I added some interesting debug possibility in my "pie" branch. copy
debugfs.c over and you can use
|cat /sys/kernel/debug/rtl838x/drop_counters|
to see why the switch drops packets.
To debug the issues in master you could comment out the things done in
dsa.c:rtl83xx_vlan_setup(). The only critical one for the multicast is
the setup of the vlans in the loop below
// Initialize all vlans 0-4095
Birger
||
On 08/05/2021 15:32, Bjørn Mork wrote:
Birger Koblitz<[email protected]> writes:
Dear Russel,
depending on how a particular device was configured previously by
u-boot, this commit might have enabled proper vlan-filtering for the
first time on your device. The default vlan-configuration has port 1
configured as management port with vlan-id 100. So your DHCP server
would need to answer with this vlan-id. Could you check that
- before the commit, the device was actually filtering vlans
- after the commit you have a correct vlan configuration on the device
talking to the switch on port 1 and that this corresponds to the
vlan configuration of that port
Does the latest master work for you?
I see the same issues Russell reports. With a config like:
root@OpenWrt:/# bridge vlan
port vlan-id
lan1 1 PVID Egress Untagged
100
lan2 1 PVID Egress Untagged
100
lan3 1 PVID Egress Untagged
lan4 1 PVID Egress Untagged
lan5 1 PVID Egress Untagged
lan6 1 PVID Egress Untagged
lan7 1 PVID Egress Untagged
lan8 1 PVID Egress Untagged
switch 1
100
root@OpenWrt:/# ifconfig switch.100
switch.100 Link encap:Ethernet HWaddr BE:A5:11:9F:E1:23
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::bca5:11ff:fe9f:e123/64 Scope:Link
inet6 addr: fd49:b68c:340b::1/60 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:1360 (1.3 KiB)
Looks like packets coming into port lan2 tagged with vlan id 100 are
dropped:
root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
^C
--- 192.168.100.111 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# ip ne sh
192.168.100.111 dev switch.100 FAILED
The other end, connected to lan2, sees the tagged arps and replies. So I
believe these must be dropped on ingress to the switch:
17055 May 8, 2021 15:23:00.973571758 CEST be:a5:11:9f:e1:23
ff:ff:ff:ff:ff:ff 100 ARP Who has 192.168.100.111? Tell
192.168.100.1
17056 May 8, 2021 15:23:00.973594729 CEST 34:97:f6:5d:03:11
be:a5:11:9f:e1:23 100 ARP 192.168.100.111 is at 34:97:f6:5d:03:11
17057 May 8, 2021 15:23:01.593254696 CEST 80:e8:6f:97:78:01
01:80:c2:00:00:00 STP Conf. Root = 32768/37/80:e8:6f:97:78:00
Cost = 0 Port = 0x8001
17058 May 8, 2021 15:23:02.013561194 CEST be:a5:11:9f:e1:23
ff:ff:ff:ff:ff:ff 100 ARP Who has 192.168.100.111? Tell
192.168.100.1
17059 May 8, 2021 15:23:02.013572143 CEST 34:97:f6:5d:03:11
be:a5:11:9f:e1:23 100 ARP 192.168.100.111 is at 34:97:f6:5d:03:11
Reverting the two commits
cde31976e375 ("realtek: Add support for Layer 2 Multicast")
4342d27ec90c ("realtek: Setup all VLANs with default configurations")
fixes the problem. I guess 4342d27ec90c is the critical one. Just
reverting both to avoid having to manually fixup anything for this
simple test.
With exactly the same config as above:
root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
64 bytes from 192.168.100.111: seq=0 ttl=64 time=1.714 ms
64 bytes from 192.168.100.111: seq=1 ttl=64 time=0.866 ms
^C
--- 192.168.100.111 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.866/1.290/1.714 ms
root@OpenWrt:/# ip ne sh
192.168.100.111 dev switch.100 lladdr 34:97:f6:5d:03:11 REACHABLE
Bjørn
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
