"I looked into it deeper, the driver does rxvlan offloading." Is this part of the driver upstream or are you using a vendor tree from Freescale which has that change included?
On 8/4/2020 7:14 AM, Gaube, Marvin (THSE-TL1) wrote: > Hello, > I looked into it deeper, the driver does rxvlan offloading. > By disabling it manually trough ethtool, the behavior becomes as expected. > > I've taken "net: dsa: sja1105: disable rxvlan offload for the DSA master" > from > (https://lore.kernel.org/netdev/20200512234921.25460-1-olte...@gmail.com/) > and also applied it to the KSZ9477-Driver, which fixes the problem. > It's probably a workaround, but fixes the VLAN behavior for now. I would > suggest also applying "ds->disable_master_rxvlan = true;" to KSZ9477 after > the mentioned patch is merged. > > Best Regards > Marvin Gaube > > -----Ursprüngliche Nachricht----- > Von: Gaube, Marvin (THSE-TL1) > Gesendet: Donnerstag, 30. Juli 2020 11:35 > An: 'Florian Fainelli' <f.faine...@gmail.com>; Woojung Huh > <woojung....@microchip.com>; Microchip Linux Driver Support > <unglinuxdri...@microchip.com> > Cc: netdev@vger.kernel.org > Betreff: AW: AW: PROBLEM: (DSA/Microchip): 802.1Q-Header lost on KSZ9477-DSA > ingress without bridge > > Hello, > the following was tested: > > ip link add name br0 type bridge > echo 1 >/sys/class/net/br0/bridge/vlan_filtering > ip link set dev lan1 master br0 > ip link set dev lan1 up > ip link set dev br0 up > bridge vlan show >> port vlan-id >> lan1 1 PVID Egress Untagged >> br0 1 PVID Egress Untagged > tcpdump -i br0 -e >> de:1c:87:(..) (oui Unknown) > 33:33:00:01:00:06 (oui Unknown), ethertype >> IPv6 (0x86dd), length 308 ... > bridge vlan del dev lan1 vid 1 > bridge vlan add dev lan1 vid 21 tagged > bridge vlan show >> port vlan-id >> lan1 21 >> br0 1 PVID Egress Untagged > tcpdump -i br0 -e >> Nothing. The frames with VLAN 21 ingress should appear here > bridge vlan del dev lan1 vid 21 > bridge vlan add dev lan1 vid 25 pvid > bridge vlan show >> port vlan-id >> lan1 25 PVID >> br0 1 PVID Egress Untagged > tcpdump -i br0 -e >> de:1c:87:(..) (oui Unknown) > 33:33:00:01:00:06 (oui Unknown), ethertype >> 802.1Q (0x8100), length 312: vlan 25, p 0, ethertype IPv6 ... > > When I tcpdump onto eth1, I see the packets with 0x8100 vid 21 all the time. > > The MAC driver is freescale/fec on imx7d (compatible string in device tree: > "fsl,imx7d-fecfsl,imx6sx-fec"). > It seems, that it not sets NETIF_F_HW_VLAN_CTAG_FILTER. > > Best Regards > Marvin Gaube > > -----Ursprüngliche Nachricht----- > Von: Florian Fainelli <f.faine...@gmail.com> > Gesendet: Mittwoch, 29. Juli 2020 17:03 > An: Gaube, Marvin (THSE-TL1) <marvin.ga...@tesat.de>; Woojung Huh > <woojung....@microchip.com>; Microchip Linux Driver Support > <unglinuxdri...@microchip.com> > Cc: netdev@vger.kernel.org > Betreff: Re: AW: PROBLEM: (DSA/Microchip): 802.1Q-Header lost on KSZ9477-DSA > ingress without bridge > > > > On 7/29/2020 7:49 AM, Gaube, Marvin (THSE-TL1) wrote: >> Hello, >> I just tried a VLAN-enabled bridge. >> All ingress packets definitely have the 802.1q-Tag on CPU ingress, >> double-checked that. Tried again with VLAN21-Tagged frames coming in the >> physical port. >> It seems that the bridge also handles all packets from lan1 as untagged. >> When I add lan1 to the bridge, the following happens: >> >> If lan1 has (only) VLAN 21 tagged on the bridge, no packet appears. >> As soon as I add an untagged/pvid VLAN to lan1 on the bridge, all packets >> appear on the bridge with whichever VLAN I added. >> I checked simultaneously with the CPU Ingress-Port (eth1), the same packets >> had Ethertype 8100 with VLAN 21 when they entered CPU. > > Can you share the commands you use to set-up your bridge with VLAN filtering > and VLAN21 added to the VLAN database of the bridge for lan1? > >> >> With Switchport 1, the physical switch port of the KSZ is meant. > > OK. > >> >> About the last thing: VLAN tagged frames are definitively passed to the CPU. >> If I "tcpdump -xx" onto eth1, I see for example "(12 byte MAC) 8100 0015 >> 86dd (IPv6-Payload)". The tail tag is also visible. >> Exactly the same frame appears on lan1 as "(12 byte MAC) 86dd >> (IPv6-Payload)", so the 802.1q-Header is present on CPU ingress. >> Therefore the VLAN tag probably is lost between eth1 (Ingress) and the >> respective DSA-Interface, and is not filtered on the KSZ9477. > > What Ethernet controller driver is eth1, does it support VLAN receive filter > (NETIF_F_HW_VLAN_CTAG_FILTER)? > >> >> Best Regards >> Marvin Gaube >> >> -----Ursprüngliche Nachricht----- >> Von: Florian Fainelli <f.faine...@gmail.com> >> Gesendet: Mittwoch, 29. Juli 2020 15:48 >> An: Gaube, Marvin (THSE-TL1) <marvin.ga...@tesat.de>; Woojung Huh >> <woojung....@microchip.com>; Microchip Linux Driver Support >> <unglinuxdri...@microchip.com> >> Cc: netdev@vger.kernel.org >> Betreff: Re: PROBLEM: (DSA/Microchip): 802.1Q-Header lost on >> KSZ9477-DSA ingress without bridge >> >> >> >> On 7/28/2020 11:05 PM, Gaube, Marvin (THSE-TL1) wrote: >>> Summary: 802.1Q-Header lost on KSZ9477-DSA ingress without bridge >>> Keywords: networking, dsa, microchip, 802.1q, vlan Full description: >>> >>> Hello, >>> we're trying to get 802.1Q-Tagged Ethernet Frames through an KSZ9477 >>> DSA-enabled switch without creating a bridge on the kernel side. >> >> Does it work if you have a bridge that is VLAN aware though? If it does, >> this would suggest that the default VLAN behavior without a bridge is too >> restrictive and needs changing. >> >>> Following setup: >>> Switchport 1 <-- KSZ9477 --> eth1 (CPU-Port) <---> lan1 >> >> This representation is confusing, is switchport 1 a network device or is >> this meant to be physical switch port number of 1 of the KSZ9477? >> >>> >>> No bridge is configured, only the interface directly. Untagged packets are >>> working without problems. The Switch uses the ksz9477-DSA-Driver with >>> Tail-Tagging ("DSA_TAG_PROTO_KSZ9477"). >>> When sending packets with 802.1Q-Header (tagged VLAN) into the Switchport, >>> I see them including the 802.1Q-Header on eth1. >>> They also appear on lan1, but with the 802.1Q-Header missing. >>> When I create an VLAN-Interface over lan1 (e.g. lan1.21), nothing arrives >>> there. >>> The other way around, everything works fine: Packets transmitted into >>> lan1.21 are appearing in 802.1Q-VLAN 21 on the Switchport 1. >>> >>> I assume that is not the intended behavior. >>> I haven't found an obvious reason for this behavior yet, but I suspect the >>> VLAN-Header gets stripped of anywhere around "dsa_switch_rcv" in >>> net/dsa/dsa.c or "ksz9477_rcv" in net/dsa/tag_ksz.c. >> >> Not sure how though, ksz9477_rcv() only removes the trail tag, this should >> leave any header intact. It seems to me that the switch is incorrectly >> configured and is not VLAN aware at all, nor passing VLAN tagged frames >> through on ingress to CPU when it should. >> -- >> Florian >> >> ________________________________ >> >> Tesat-Spacecom GmbH & Co. KG >> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977 >> Persoenlich haftender Gesellschafter: Tesat-Spacecom >> Geschaeftsfuehrungs GmbH; >> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658; >> Geschaeftsfuehrung: Dr. Marc Steckling, Kerstin Basche, Ralf >> Zimmermann >> >> [banner] >> > > -- > Florian > -- Florian
