| 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
| ||
|
Message-ID: <0F1324C1-5E17-42AF-B8EC-C999B1537F59@public-files.de>
Date: Thu, 13 Apr 2023 23:30:14 +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>,
Frank Wunderlich <frank-w@...lic-files.de>
Subject: Re: Choose a default DSA CPU port
Am 13. April 2023 20:09:52 MESZ schrieb Frank Wunderlich <frank-w@...lic-files.de>:
>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
tried from my laptop wirh additional usb2eth adapter and see no bpdu
$ sudo mausezahn enx00e04c6c1dd3 -b 01:80:c2:00:00:00 -c 5 -t bpdu
0.00 seconds (22727 packets per second)
connected lan0 (eth0) to my laptop and wan to my switch (changed this to eth1)
eth0 is empty, eth1 contains some packets (but this is not where i sent the bpdu)
seems dsa-user-port does not accept packets to this mac...do not see them on lan0 interface too
regards Frank
Powered by blists - more mailing lists