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: <87wn1foze1.fsf@waldekranz.com> Date: Thu, 11 May 2023 13:56:06 +0200 From: Tobias Waldekranz <tobias@...dekranz.com> To: Fabio Estevam <festevam@...il.com> Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Steffen Bätz <steffen@...osonix.de>, netdev <netdev@...r.kernel.org> Subject: Re: mv88e6320: Failed to forward PTP multicast On tor, maj 11, 2023 at 08:16, Fabio Estevam <festevam@...il.com> wrote: > Hi Tobias, > > On Wed, May 10, 2023 at 6:34 PM Tobias Waldekranz <tobias@...dekranz.com> wrote: > >> If possible, could you install mdio-tools and paste the output of `mvls` >> on your board from the two configurations above? >> >> Unfortunately, you will have to patch it to support your device. Based >> on a quick view of the datasheet, this should probably work: > > I have installed mdio-tools with the suggested patch to support 88E6320. Good, that seems to at least partially work. From the VTU dump (first table), we can see that all VLANs appear to be using FID 0, which they shouldn't do. Do you have any patches on mv88e6xxx? It might also be a bug in mvls, in that Pearl is not completely compatible with Opal w.r.t to the VTU. > Please find attached two tests with their mvls results. > > Test 1: netconfig_PTP30s_mvls_test.sh In this case, we can see that the PTP group (224.0.1.129, aka 01:00:5e:00:01:81) is not in the ATU. Therefore, the message will be flooded to all ports that allow flooding of unknown multicast, i.e. have their "m" bit set in the "FL" column of the port table. Therefore, you should see the packet both on the CPU and on eth2. This assumes that there is no active config to trap PTP packets. I am not familiar with how that is setup. To verify this, you can run a tcpdump on the interface connected to the cpu port of the switch, with the "-e" flag set, and check whether the PTP packets arrive with a FORWARD or a TO_CPU tag. > Test 2: netconfig_NOPTP_mvls_test.sh In this case, this line in the ATU... 01:00:5e:00:01:81 0 static - - . . . 3 4 . . Shows that the group is treated as registered multicast, and is therefore only allowed to egress through port 3 (eth1) and 4 (eth2). You should therefore see it on eth2, but it would not show up at the CPU. I imagine that if you were to open a socket and add a membership to the group, the packets would reach the CPU. What happens if you run: socat udp-recvfrom:1234,ip-add-membership=224.0.1.129:br0 gopen:/dev/null & Can you see the PTP packets on the CPU now? > The only difference between these two tests is that the second one adds: > ip link set dev br0 type bridge vlan_filtering 1 > > In the first case, PTP traffic is seen for about 30 seconds and then it stops. > In the second case, no PTP traffic is seen at all. I would guess that this is when br0 gives up on finding a multicast router on the network, and assumes the role of querier. How does the output of mvls change before and after this point in time?
Powered by blists - more mailing lists