Fwd: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

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<mail at birger-koblitz.de>  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 at 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 at 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 at 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 at 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 at 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 at 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
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel