Re: mv88e6320: Failed to forward PTP multicast

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, May 16, 2023 at 06:29:13PM +0200, Andrew Lunn wrote:
> > When I get into this "blocked" situation if I restart the bridge manually:
> > ip link set br0 down
> > ip link set br0 up
> > 
> > Then tcpdump starts showing the PTP traffic again, but only for a
> > short duration of time, and stops again.
> > 
> > Now that I have a more reliable way to reproduce the issue, I can run
> > more tests/debugging.
> > Please let me know if you have any suggestions.
> 
> This behaviour sounds like IGMP snooping, or something like that. The
> bridge is adding in an entry to say don't send the traffic to the CPU,
> nobody is interested in it.

This is more to Fabio: right now I don't really understand what's the
problem. In the initial message you reported that the switch doesn't
forward IPv4 PTP between bridged ports, but I guess that's not true?
Or if it is, the lack of IPv4 PTP in the tcpdump output on br0 is
completely unrelated. It would help if you could restate the real issue.

> I would add some debug prints into mv88e6xxx_port_fdb_add(),
> mv88e6xxx_port_fdb_del() mv88e6xxx_port_mdb_add() and
> mv88e6xxx_port_mdb_del() and see what entries are getting. You can
> then backtrack and see why the bridge is adding them.

FWIW, there's also a more "modern" way of debugging in net-next, which
is either to put "trace_event=dsa" in the kernel cmdline and to
cat /sys/kernel/debug/tracing/trace, or to run "trace-cmd record -e dsa <command ...>"
followed by "trace-cmd report".

> 
> Also, Tobias asked about the type of frame being passed from the
> switch to the host for PTP frames. Is it TO_CPU or FORWARD?  tcpdump
> -e on the FEC interface will show you additional information in the
> DSA header.

Seeing that these come and go to the host (eth0) based on the presence
of the 01:00:5e:00:01:81 entry in the ATU, I'd say these come with a
FORWARD tag, but indeed it would be good to confirm. Only
MV88E6XXX_VID_STANDALONE is installed with vlan.policy = true,
the others aren't, so I don't see a reason why IPv4 PTP would reach the
CPU via a trap here.