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: <b2a5d9d6-5ae5-405f-b050-caa95807dd7c@lunn.ch>
Date: Tue, 16 May 2023 18:29:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Fabio Estevam <festevam@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, tobias@...dekranz.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

> 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.

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.

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.

   Andrew