| 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
| ||
|
Date: Thu, 13 Apr 2023 20:09:52 +0200
From: Frank Wunderlich <frank-w@...lic-files.de>
To: Vladimir Oltean <olteanv@...il.com>
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: Aw: Re: Choose a default DSA CPU port
Hi
> Gesendet: Dienstag, 07. März 2023 um 19:43 Uhr
> Von: "Vladimir Oltean" <olteanv@...il.com>
> Betreff: 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
hi i tried last approach on bananapi r64 as it is the one and only board i have with mt7531 which has both gmacs connected to the switch.
base is my 6.3-rc tree (modified r64 dts for having second gmac):
https://github.com/frank-w/BPI-Router-Linux/commits/6.3-rc
root@...-r64:~# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP group default qlen 1000
link/ether 66:ea:04:18:30:6f brd ff:ff:ff:ff:ff:ff
root@...-r64:~# ip a s eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 86:97:05:8f:80:63 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8497:5ff:fe8f:8063/64 scope link
valid_lft forever preferred_lft forever
root@...-r64:~# tcpdump -i eth0 > eth0.log &
[1] 3774
e
listening on eth0, link-type NULL (BSD loopback), snapshot length 262144 bytes
root@...-r64:~# tcpdump -i eth1 > eth1.log &
[2] 3779
e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
root@...-r64:~# mausezahn eth0 -b 01:80:c2:00:00:00 -c 5 -t bpdu
0.00 seconds (30864 packets per second)
root@...-r64:~# killall tcpdump
5 packets captur[ 2981.315951] mtk_soc_eth 1b100000.ethernet eth1: left promiscuous mode
ed
5 packets received by filter
0 packets dropped by kernel
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[1]- Done tcpdump -i eth0 > eth0.log
[2]+ Done tcpdump -i eth1 > eth1.log
root@...-r64:~# cat eth0.log
20:04:47.124519 AF Unknown (25215488), length 60:
0x0000: 0000 66ea 0418 306f 0026 4242 0300 0000 ..f...0o.&BB....
0x0010: 0000 0000 66ea 0418 306f 0000 0000 0000 ....f...0o......
0x0020: 66ea 0418 306f 0000 0000 1400 0200 0f00 f...0o..........
0x0030: 0000 0000 0000 0000 ........
20:04:47.124555 AF Unknown (25215488), length 60:
0x0000: 0000 66ea 0418 306f 0026 4242 0300 0000 ..f...0o.&BB....
0x0010: 0000 0000 66ea 0418 306f 0000 0000 0000 ....f...0o......
0x0020: 66ea 0418 306f 0000 0000 1400 0200 0f00 f...0o..........
0x0030: 0000 0000 0000 0000 ........
20:04:47.124568 AF Unknown (25215488), length 60:
0x0000: 0000 66ea 0418 306f 0026 4242 0300 0000 ..f...0o.&BB....
0x0010: 0000 0000 66ea 0418 306f 0000 0000 0000 ....f...0o......
0x0020: 66ea 0418 306f 0000 0000 1400 0200 0f00 f...0o..........
0x0030: 0000 0000 0000 0000 ........
20:04:47.124580 AF Unknown (25215488), length 60:
0x0000: 0000 66ea 0418 306f 0026 4242 0300 0000 ..f...0o.&BB....
0x0010: 0000 0000 66ea 0418 306f 0000 0000 0000 ....f...0o......
0x0020: 66ea 0418 306f 0000 0000 1400 0200 0f00 f...0o..........
0x0030: 0000 0000 0000 0000 ........
20:04:47.124592 AF Unknown (25215488), length 60:
0x0000: 0000 66ea 0418 306f 0026 4242 0300 0000 ..f...0o.&BB....
0x0010: 0000 0000 66ea 0418 306f 0000 0000 0000 ....f...0o......
0x0020: 66ea 0418 306f 0000 0000 1400 0200 0f00 f...0o..........
0x0030: 0000 0000 0000 0000 ........
root@...-r64:~# cat eth1.log
root@...-r64:~#
so it looks like packets are not duplicated
regards Frank
Powered by blists - more mailing lists