netdev - Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

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: <20250629112830.79975f4a@wsk>
Date: Sun, 29 Jun 2025 11:28:30 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Richard Cochran
 <richardcochran@...il.com>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
 netdev@...r.kernel.org, Arun Ramadoss <arun.ramadoss@...rochip.com>,
 Tristram.Ha@...rochip.com, Christian Eggers <ceggers@...i.de>
Subject: Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477
 device

Hi Vladimir,

> On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> > The second problem which I've found after some debugging:
> > - One device is selected as grandmaster clock. Another one tries to
> >   synchronize (for the simpler setup I've used two the same boards
> > with identical kernel and KSZ9477 setup).
> > 
> > - tshark from host on which we do have grandmaster running:
> >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> > 
> > So the SYNC is send, then the "slave" responds correctly with
> > Peer_Delay_Req_Message.  
> 
> Peer delay measurement is an independent process, not a response to
> Sync messages.
> 
> > But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.
> > 
> > After some digging into the code it turned out that
> > dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
> > ptp_classify_raw(skb), which is a bpf program.
> > 
> > Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the
> > frame is dropped.
> > 
> > That is why grandmaster cannot send reply and finish the PTP clock
> > adjustment process.
> > 
> > The CONFIG_NET_PTP_CLASSIFY=y.
> > 
> > Any hints on how to proceed? If this would help - I'm using linux
> > kernel with PREEMPT_RT applied to it.  
> 
> Which frame is classified as PTP_CLASS_NONE? The peer delay request?
> That doesn't sound convincing, can you place a call to skb_dump() and
> show the contents of the PTP packets that don't pass this BPF filter?
> Notably, the filter matches for event messages and doesn't match for
> general messages, maybe that confused your debugging process in some
> way.

It looks like PER_DELAY_REQ goes from one KSZ9477 device (with DA:
01:80:C2:00:00:0E) and then it is not visible (i.e. is dropped) in the
tshark output on the other KSZ9477 device.

From what I've read on the Internet - those multicast frames are
dropped by default by switches, but I'm using KSZ9477 ports in
stand alone mode - i.e. bridge is not created).

On the other hand - the frames with DA: 01:16:19:00:00:00 (other
multicast "set" of address) are delivered correctly (so the grandmaster
clock is elected).

This is under further investigation.
(setting KSZ9477 lan3s as promisc doesn't help).


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped