netdev - Re: dsa/mv88e6xxx: leaking packets on MV88E6341 switch

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201201090041.GB6059@unassigned-hostname.unassigned-domain>
Date:   Tue, 1 Dec 2020 10:00:42 +0100
From:   Peter Vollmer <peter.vollmer@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: dsa/mv88e6xxx: leaking packets on MV88E6341 switch

On Thu, Nov 26, 2020 at 11:23:59PM +0100, Andrew Lunn wrote:
> > > I tested setting .tag_protocol=DSA_TAG_PROTO_DSA for the 6341 switch
> > > instead, resulting in a register setting of 04 Port control for port 5
> > > = 0x053f (i.e. EgressMode=Unmodified mode, frames are transmitted
> > > unmodified), which looks correct to me. It does not fix the above
> > > problem, but the change seems to make sense anyhow. Should I send a
> > > patch ?
> > 
> > This is not up to me, but my guess is that Andrew would like a patch,
> > yes. On 6390X, I know for a fact that setting the EgressMode to 3 does
> > indeed produce the behavior that was supported in older devices (like
> > the 6352), but there is no reason not to change it to regular DSA.
> 
> I already said to Tobias, i had problems getting the 6390 working, and
> this was one of the things i changed. I don't think i ever undid this
> specific change, to see how critical it is. But relying on
> undocumented behaviour is not nice.
> 
> EDSA used to have the advantages that tcpdump understood it. But
> thanks to work Florian and Vivien did, tcpdump can now decode DSA just
> as well as EDSA.
> 
> So please do submit a patch.

I checked both cases (EDSA, DSA) with tcpdump on eth1 (SGMII to the switch),
they both seem to work and tcpdump recognizes two different formats, MEDSA for
DSA_TAG_PROTO_EDSA and "ethertype unknown (0x4018 (or 0xc018))" for
DSA_TAG_PROTO_DSA (due to an older tcpdump version 4.9.3 I guess). Maybe I can
get some information from our support if DSA_TAG_PROTO_EDSA is supported
for the port config (0x4) register on the 6341 switch after all or if it should
be omitted.

Thanks

  Peter