Re: [PATCH net-next 4/4] net: mscc: ocelot: set up traps for PTP packets

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Fri, Nov 26, 2021 at 08:58:47AM -0800, Richard Cochran wrote:
> On Fri, Nov 26, 2021 at 01:21:18AM +0200, Vladimir Oltean wrote:
> 
> > So PTP over L2 barely works, in the sense that PTP packets reach the CPU
> > port, but they reach it via flooding, and therefore reach lots of other
> > unwanted destinations too. But PTP over IPv4/IPv6 does not work at all.
> > This is because the Ocelot switch have ...
> 
> Not that the details are same, but I'd like to report that the Marvell
> switches (or driver or kernel) also have issues with PTP over UDP/IPv4.
> 
> When configured with separate interfaces, not in a bridge, you can run
> ptp4l as a UDP/IPv4 Boundary Clock, and it works fine.
> 
> When configured as a bridge, and running ptp4l as a UDP/IPv4
> Transparent Clock, it doesn't work.  It has been a while, and I don't
> have the HW any more, but I don't recall the exact behavior.  I think
> the switch did not treat the Event frames as switch management frames.
> 
> (BTW, running ptp4l TC over Layer-2 worked just fine with the switch
> configured as a bridge.)
> 
> Just saying, in case somebody with such a switch would like to try and
> fix the driver by adding special forwarding rules for the IPv4/6
> multicast addresses.

This, to me, sounds more like the bridge trapping the packets on br0
instead of letting them flow on the port netdevices, which is solved by
some netfilter rules? Or is it really a driver/hardware issue?

https://lore.kernel.org/netdev/20211116102138.26vkpeh23el6akya@skbuf/