realtek: Setup all VLANs with default configurations
Birger Koblitz
mail at birger-koblitz.de
Sat May 8 17:17:32 BST 2021
yes, counters are reset on every read.
I guess I should have learned to do more vlan-testing.
I'll try to figure out what is going on.
Birger
On 08/05/2021 17:39, Bjørn Mork wrote:
> Birger Koblitz <mail at birger-koblitz.de> writes:
>
>> 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 don't think it's suficient to test without vlan tagging when messing
> around with the vlan config on these switches. Experience has shown that
> there are a number of possible and real failure modes, where you forward
> with wrong tagging or filter on the wrong vid.
>
>
> But I'm not convinced it works so well for the default either... I see
> this received on the native VLAN 1:
>
>
> canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67'
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'xeth0'
> Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on interface 0
> Interface id: 0 (xeth0)
> Interface name: xeth0
> Encapsulation type: Ethernet (1)
> Arrival Time: May 8, 2021 16:56:20.581072322 CEST
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1620485780.581072322 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 346 bytes (2768 bits)
> Capture Length: 346 bytes (2768 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:udp:bootp]
> Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff
> Destination: ff:ff:ff:ff:ff:ff
> Address: ff:ff:ff:ff:ff:ff
> .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
> .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
> Source: bc:a5:11:9f:e1:23
> Address: bc:a5:11:9f:e1:23
> .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43
> [Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]]
> [Bad checksum [should be 0x63ff5c43]]
> [Severity level: Error]
> [Group: Checksum]
> [FCS Status: Bad]
> Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
> Total Length: 328
> Identification: 0x0000 (0)
> Flags: 0x0000
> 0... .... .... .... = Reserved bit: Not set
> .0.. .... .... .... = Don't fragment: Not set
> ..0. .... .... .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: UDP (17)
> Header checksum: 0x79a6 [validation disabled]
> [Header checksum status: Unverified]
> Source: 0.0.0.0
> Destination: 255.255.255.255
> User Datagram Protocol, Src Port: 68, Dst Port: 67
> Source Port: 68
> Destination Port: 67
> Length: 308
> Checksum: 0xd82b [unverified]
> [Checksum Status: Unverified]
>
> [etc]
>
>
>
> That seemingly magic number 0x80091000 instead of the expected FCS is
> pretty suspicious. Leaking tag? Or what?
>
>> 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.
>
>
>
> root at OpenWrt:/# cat /sys/kernel/debug/rtl838x/drop_counters
> ALE_TX_GOOD_PKTS: 74
> MAC_RX_DROP: 0
> ACL_FWD_DROP: 0
> HW_ATTACK_PREVENTION_DROP: 0
> RMA_DROP: 0
> VLAN_IGR_FLTR_DROP: 0
> INNER_OUTER_CFI_EQUAL_1_DROP: 0
> PORT_MOVE_DROP: 0
> NEW_SA_DROP: 0
> MAC_LIMIT_SYS_DROP: 0
> MAC_LIMIT_VLAN_DROP: 0
> MAC_LIMIT_PORT_DROP: 0
> SWITCH_MAC_DROP: 0
> ROUTING_EXCEPTION_DROP: 0
> DA_LKMISS_DROP: 0
> RSPAN_DROP: 0
> ACL_LKMISS_DROP: 0
> ACL_DROP: 0
> INBW_DROP: 0
> IGR_METER_DROP: 0
> ACCEPT_FRAME_TYPE_DROP: 0
> STP_IGR_DROP: 3
> INVALID_SA_DROP: 0
> SA_BLOCKING_DROP: 0
> DA_BLOCKING_DROP: 0
> L2_INVALID_DPM_DROP: 0
> MCST_INVALID_DPM_DROP: 0
> RX_FLOW_CONTROL_DROP: 0
> STORM_SPPRS_DROP: 0
> LALS_DROP: 0
> VLAN_EGR_FILTER_DROP: 33
> STP_EGR_DROP: 0
> SRC_PORT_FILTER_DROP: 10
> PORT_ISOLATION_DROP: 0
> ACL_FLTR_DROP: 0
> MIRROR_FLTR_DROP: 0
> TX_MAX_DROP: 0
> LINK_DOWN_DROP: 0
> FLOW_CONTROL_DROP: 0
> BRIDGE .1d discards: 0
> 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 ---
> 5 packets transmitted, 0 packets received, 100% packet loss
> root at OpenWrt:/# cat /sys/kernel/debug/rtl838x/drop_counters
> ALE_TX_GOOD_PKTS: 35
> MAC_RX_DROP: 0
> ACL_FWD_DROP: 0
> HW_ATTACK_PREVENTION_DROP: 0
> RMA_DROP: 0
> VLAN_IGR_FLTR_DROP: 0
> INNER_OUTER_CFI_EQUAL_1_DROP: 0
> PORT_MOVE_DROP: 0
> NEW_SA_DROP: 0
> MAC_LIMIT_SYS_DROP: 0
> MAC_LIMIT_VLAN_DROP: 0
> MAC_LIMIT_PORT_DROP: 0
> SWITCH_MAC_DROP: 0
> ROUTING_EXCEPTION_DROP: 0
> DA_LKMISS_DROP: 0
> RSPAN_DROP: 0
> ACL_LKMISS_DROP: 0
> ACL_DROP: 0
> INBW_DROP: 0
> IGR_METER_DROP: 0
> ACCEPT_FRAME_TYPE_DROP: 0
> STP_IGR_DROP: 0
> INVALID_SA_DROP: 0
> SA_BLOCKING_DROP: 0
> DA_BLOCKING_DROP: 0
> L2_INVALID_DPM_DROP: 0
> MCST_INVALID_DPM_DROP: 0
> RX_FLOW_CONTROL_DROP: 0
> STORM_SPPRS_DROP: 0
> LALS_DROP: 0
> VLAN_EGR_FILTER_DROP: 0
> STP_EGR_DROP: 0
> SRC_PORT_FILTER_DROP: 2
> PORT_ISOLATION_DROP: 0
> ACL_FLTR_DROP: 0
> MIRROR_FLTR_DROP: 0
> TX_MAX_DROP: 0
> LINK_DOWN_DROP: 0
> FLOW_CONTROL_DROP: 0
> BRIDGE .1d discards: 0
>
>
> Not sure I learned anything useful from this. Are the counters reset on
> every read?
>
>
>> 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
> That's pretty much everything it does, isn't it? :-)
>
> In any case, I tried it now with this and it does make the VLAN stuff
> work again (still same issue with the FCS on the DHCP requests):
>
> diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
> index c5f243c55abd..d972bf6ff8b9 100644
> --- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
> +++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
> @@ -119,8 +119,8 @@ static void rtl83xx_vlan_setup(struct rtl838x_switch_priv *priv)
>
> pr_info("In %s\n", __func__);
>
> - priv->r->vlan_profile_setup(0);
> - priv->r->vlan_profile_setup(1);
> +// priv->r->vlan_profile_setup(0);
> +// priv->r->vlan_profile_setup(1);
> pr_info("UNKNOWN_MC_PMASK: %016llx\n", priv->r->read_mcast_pmask(UNKNOWN_MC_PMASK));
> priv->r->vlan_profile_dump(0);
>
>
> The difference seems to be related to whether the CPU port(?) is a
> member of UNKNOWN_MC_PMASK or not. Failing:
>
> [ 7.615045] UNKNOWN_MC_PMASK: 000000000fffffff
> [ 7.620099] VLAN profile 0: L2 learning: 1, UNKN L2MC FLD PMSK 511, UNKN IPMC FLD PMSK 511, UNKN IPv6MC FLD PMSK: 511
>
> Working:
>
> [ 7.625941] UNKNOWN_MC_PMASK: 000000001fffffff
> [ 7.630907] VLAN profile 0: L2 learning: 1, UNKN L2MC FLD PMSK 511, UNKN IPMC FLD PMSK 511, UNKN IPv6MC FLD PMSK: 511
>
>
>
> Actually, you don't have to disable the profile_setups. This change is
> sufficient to make VLANs work (at least in the limited testing I've done):
>
>
> diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> index dfd773c5e6fc..5d764b6a32d6 100644
> --- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> +++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> @@ -398,7 +398,7 @@ static void rtl838x_vlan_profile_setup(int profile)
> * On RTL93XX, the portmask is directly set in the profile,
> * see e.g. rtl9300_vlan_profile_setup
> */
> - rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfffffff);
> + rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fffffff);
> }
>
> static inline int rtl838x_vlan_port_egr_filter(int port)
>
>
> No idea why or how. Just a magic value with a magic result, like most
> of the code.
>
> I really don't think these changes have been tested well enough to be
> pushed into openwrt master yet. Based on this first impression, I would
> be surprised if there isn't more broken stuff.
>
>
>
> Bjørn
>
More information about the openwrt-devel
mailing list