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: <CAOMZO5BcwgujANLguNXCCZvJh8jwqUAcuu63D8dhwGhZ6oHffA@mail.gmail.com>
Date: Tue, 16 May 2023 11:12:14 -0300
From: Fabio Estevam <festevam@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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

Hi Vladimir,

On Thu, May 11, 2023 at 8:46 AM Vladimir Oltean <olteanv@...il.com> wrote:

> I don't see the "eth0" name referenced in any of the attached files. By
> "connected to the i.MX8MN" you mean "separate from the board under test",
> right? To be more specific, it is always connected to the eth2 switch
> port, correct?

Our system looks like this:

https://ibb.co/F7d1tnK

I realized that I provided several scripts and that made things confusing.
Sorry about that.

I found a simpler and more reliable way to reproduce the problem.

Script 1: Non-VLAN-aware bridge script

ip link add br0 type bridge vlan_filtering 0
ip link set eth1 master br0
ip link set eth2 master br0
ip addr add 192.168.0.97/24 dev br0
ip link set br0 up
tcpdump -i br0 dst port 319 or dst port 320

Script 2: VLAN-aware bridge script

ip link add br0 type bridge vlan_filtering 1
ip link set eth1 master br0
ip link set eth2 master br0
ip addr add 192.168.0.97/24 dev br0
ip link set br0 up
tcpdump -i br0 dst port 319 or dst port 320

(only difference between them is 'vlan_filtering 0' versus 'vlan_filtering 1').

On the Linux PC, I run:

"sudo ptp4l -i eth0 -m"

When I run script 1 on the imx8mn board, tcpdump constantly shows the
PTP traffic.

When I run script 2 on the imx8mn board, tcpdump shows the PTP traffic only
for a short duration of time (from 10 seconds to about 1 minute) and then
it no longer shows the PTP traffic.

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.

Thanks a lot,

Fabio Estevam