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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

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@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]