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 08:58:47 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     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, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Yangbo 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 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.

Thanks,
Richard