Re: mv88e6320: Failed to forward PTP multicast

[Tobias Waldekranz <tobias@waldekranz.com>]

On tor, maj 11, 2023 at 08:16, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Tobias,
>
> On Wed, May 10, 2023 at 6:34 PM Tobias Waldekranz <tobias@waldekranz.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?