netdev - Re: mv88e6320: Failed to forward PTP multicast

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: <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?