netdev - Re: Choose a default DSA CPU port

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: <20230307174323.sbzhb7gy6blgj2jf@skbuf>
Date:   Tue, 7 Mar 2023 19:43:23 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Felix Fietkau <nbd@....name>, netdev <netdev@...r.kernel.org>,
        erkin.bozoglu@...ont.com, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        John Crispin <john@...ozen.org>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>
Subject: Re: Choose a default DSA CPU port

On Mon, Mar 06, 2023 at 07:20:25PM +0100, Frank Wunderlich wrote:
> is it possible to map this function only to mt7530, not mt7531?
> 
> as one way i would add a check for the chip
> 
> if (priv->id != ID_MT7530) { return NULL; }
> //existing content for mt7531

yeah, returning "NULL" to ds->ops->preferred_default_local_cpu_port()
would mean "don't know, don't care" and DSA would choose by itself.

although I feel we're not at the stage where we should discuss about
that just yet.

> where did you find the comment about multicast?

well, I didn't find "link-local multicast", but "BPDU to CPU port" and
may have ran a little bit too far with that info.

If you search for the "Bridge Group Address" keyword in IEEE 802.1Q or
IEEE 802.1D (older) documents, you'll see that STP BPDUs are sent to a
reserved multicast MAC DA of 01-80-C2-00-00-00, which is link-local,
meaning that switches don't forward it but trap it. Since I knew that,
I just assumed that "BPDU to CPU port" means "trapping of any frames
with that MAC DA to the CPU port", since if I were a hardware designer,
that's what I would do. It's possible to identify STP BPDUs (to trap
just those) by examining the LLC header, but I wouldn't bother since the
MAC DA is reserved for this kind of stuff and I'd be locking myself out
of being compatible with possible protocol changes in the future.

> https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/net/dsa/mt7530.c has
> "multicast" only in the packet-counters (mib_desc)
> 
> > The next most obvious thing would be L2 PTP (ptp4l -2), but since mt7530
> > doesn't support hw timestamping, you'd need to try software timestamping
> > instead ("ptp4l -i swpX -2 -P -S -m", plus the equivalent command on a
> > link partner).
> 
> have not done anything with l2 p2p yet, and no server running...i'm not sure
> i can check this the right way.

Anyway, it doesn't have to be PTP, it can be literally any application
using a PF_PACKET socket to send sequence-numbered packets towards a
mt7530 port with the 01:80:c2:00:00:00 MAC DA, and using 2 tcpdump
instances on the 2 GMACs to check whether packets are received once or
twice.

If this is still too complicated, just send 5 actual BPDUs and see if
you receive them on both CPU ports:

mausezahn eth0 -b 01:80:c2:00:00:00 -c 5 -t bpdu