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

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]

Date:   Fri, 26 Nov 2021 17:01:13 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Po Liu <po.liu@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Antoine Tenart <atenart@...nel.org>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "Y.B. Lu" <yangbo.lu@....com>, Rui Sousa <rui.sousa@....com>,
        "Allan W . Nielsen" <allan.nielsen@...rochip.com>
Subject: Re: [PATCH net-next 4/4] net: mscc: ocelot: set up traps for PTP
 packets

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/