lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <MR1P264MB3681BFFDEB416E4919D4C22CF84F2@MR1P264MB3681.FRAP264.PROD.OUTLOOK.COM>
Date: Fri, 25 Oct 2024 15:18:13 +0000
From: Hervé Gourmelon <herve.gourmelon@...nops.com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>,
	Vivien Didelot <vivien.didelot@...il.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, Tobias Waldekranz <tobias@...dekranz.com>
Subject: RE: [PATCH 1/1] net: dsa: fix tag_dsa.c for untagged VLANs


Hello Vladimir, and thanks for the answer,

On Fri, Oct 25, 2024 at 02:18:48PM +0000, Vladimir Oltean  wrote:
>> Trying to set up an untagged VLAN bridge on a DSA architecture of
>> mv88e6xxx switches, I realized that whenever I tried to emit a
>> 'From_CPU' or 'Forward' DSA packet, it would always egress with an
>> unwanted 802.1Q header on the bridge port.
>
>What does the link partner see? The packet with the 8021.Q tag or
>without it?

The link partner definitely sees the packets with the 802.1Q tags.

>The packet will always exit the Linux bridge layer as VLAN-tagged,
>because skb->offload_fwd_mark will be set*. It will appear with the VLAN
>tag in tcpdump, but it should not appear with the VLAN tag on the wire
>or on the other side, if the VLAN on the bridge port is egress-untagged.
>If you only see this in tcpdump, it is expected behavior and not a problem.

Agreed, and this also what I figured out. But even then, on the link partner, 
I would keep seeing undesired 8021.Q tags in the incoming packets, until
I patched net/dsa/tag_dsa.c as mentioned earlier.

Turning to the Marvell distributor for support (Avnet Silica) I was also given a
hint that the Src_Tagged bit had something to do with the presence of the 
IEEE tag with a 0x8100 Ether type.

Then again, this solution suits my needs (working on a set of 3 cascaded 
MV88E6097 chipsets with an EtherType-DSA link to the CPU) but I won't 
pretend I've tested it in other setups on other Marvell Link Street chipsets...

>*in turn, that is because we set tx_fwd_offload to true, and the bridge
>layer entrusts DSA that it will send the packet into the right VLAN.
>Hence the unconditional presence of the tag, and the reliance upon the
>port egress setting to strip it in hardware where needed.

I tried to figure out that part as well, but couldn't get it to work without 
my patch. I tried to restrict my patch to 'From_CPU' packets at first, but 
I would still occasionally get 'Forward' packets with the unwanted 802.1Q
tag on the link partner.

So in the end I'm sharing this, just in case someone else is stuck with the 
same problem...

Thank you for your time.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ