MIME-Version: 1.0
References: <20230317120815.321871-1-noltari@gmail.com> <00783066-a99c-4bab-ae60-514f4bce687b@lunn.ch>
In-Reply-To: <00783066-a99c-4bab-ae60-514f4bce687b@lunn.ch>
From:   Jonas Gorski <jonas.gorski@gmail.com>
Date:   Fri, 17 Mar 2023 17:49:14 +0100
Message-ID: <CAOiHx==TiSZKE4AP3PZ9Ah4zuAsrfpOTvRADWpT2kMS9UVRH9Q@mail.gmail.com>
Subject: Re: [PATCH] net: dsa: tag_brcm: legacy: fix daisy-chained switches
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     =?UTF-8?B?w4FsdmFybyBGZXJuw6FuZGV6IFJvamFz?= <noltari@gmail.com>,
        f.fainelli@gmail.com, olteanv@gmail.com, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 17 Mar 2023 at 17:32, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Mar 17, 2023 at 01:08:15PM +0100, =C3=81lvaro Fern=C3=A1ndez Roja=
s wrote:
> > When BCM63xx internal switches are connected to switches with a 4-byte
> > Broadcom tag, it does not identify the packet as VLAN tagged, so it add=
s one
> > based on its PVID (which is likely 0).
> > Right now, the packet is received by the BCM63xx internal switch and th=
e 6-byte
> > tag is properly processed. The next step would to decode the correspond=
ing
> > 4-byte tag. However, the internal switch adds an invalid VLAN tag after=
 the
> > 6-byte tag and the 4-byte tag handling fails.
> > In order to fix this we need to remove the invalid VLAN tag after the 6=
-byte
> > tag before passing it to the 4-byte tag decoding.
>
> Is there an errata for this invalid VLAN tag? Or is the driver simply
> missing some configuration for it to produce a valid VLAN tag?
>
> The description does not convince me you are fixing the correct
> problem.

This isn't a bug per se, it's just the interaction of a packet going
through two tagging CPU ports.

My understanding of the behaviour is:

1. The external switch inserts a 4-byte Broadcom header before the
VLAN tag, and sends it to the internal switch.
2. The internal switch looks at the EtherType, finds it is not a VLAN
EtherType, so assumes it is untagged, and adds a VLAN tag based on the
configured PVID (which 0 in the default case).
3. The internal switch inserts a legacy 6-byte Broadcom header before
the VLAN tag when forwarding to its CPU port.

The internal switch does not know how to handle the (non-legacy)
Broadcom tag, so it does not know that there is a VLAN tag after it.

The internal switch enforces VLAN tags on its CPU port when it is in
VLAN enabled mode, regardless what the VLAN table's untag bit says.

The result is a bogus VID 0 and priority 0 tag between the two
Broadcom Headers. The VID would likely change based on the PVID of the
port of the external switch.

Jonas