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]

Date:   Wed, 1 Mar 2023 14:37:43 +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 Wed, Mar 01, 2023 at 07:38:10AM +0100, Frank Wunderlich wrote:
> It was a userspace way to use the second ethernet lane p5-mac1 without
> defining p5 as cpu-port (and so avoiding this cpu-port handling).
> I know it is completely different,but maybe using multiple cpu-ports
> require some vlan assignment inside the switch to not always flood
> both cpu-ports with same packets. So p5 could only accept tagged
> packets which has to been tagged by userport.
> 
> How can i check if same packets processed by linux  on gmacs (in case
> i drop the break for testing)? Looking if rx increases the same way
> for both macs looks not like a reliable test.

I'd say that using a protocol with sequence numbers would be a good way
to do that. Most obvious would be ping (ICMP), but if the code comment
is right and MT7531_CFC[MT7531_CPU_PMAP_MASK] only affects link-local
multicast packet trapping (the 01:80:c2:00:00:xx MAC DA range), then
this won't do anything, because ping is unicast.

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).

When testing, make sure that both CPU ports are active and their DSA
masters are up! Otherwise, the switch may send duplicate link-local
packets to both CPU ports, but DSA would only process one of them,
leading us to believe that there isn't any duplication.

Putting a tcpdump -i eth0 -w eth0.pcap and a tcpdump -i eth1 -w eth1.pcap
in parallel would also be a good way to double-check.